CVE-2026-9828

Overview

Logback is an open-source Java logging framework designed as a successor to Log4j. Its core module provides logging infrastructure, logback-classic implements the SLF4J API, and logback-access supplies HTTP access logging for servlet containers.

An authorization bypass vulnerability (CVE-2026-9828) has been identified in the HardenedObjectInputStream class of logback-core, which allows attackers who can influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer to have objects from classes in the java.lang and java.util packages deserialized even though those classes are not on the intended whitelist. No practical path to remote code execution or significant privilege escalation has been identified, but the issue bypasses the intended deserialization restrictions.

Per OWASP: Insecure Deserialization is a type of vulnerability that arises when untrusted data is used to abuse the logic of an application's deserialization process, allowing an attacker to execute code, manipulate objects, or perform injection attacks.

This issue affects Logback versions up to and including 1.5.32.

Details

Module Info

• Product: Logback
• Affected packages: ch.qos.logback:logback-core
• Affected versions: <=1.5.32
• GitHub repository: https://github.com/qos-ch/logback
• Published packages: https://central.sonatype.com/artifact/ch.qos.logback/logback-core
• Package manager: Maven
• Fixed in:
  
  • OSS Logback 1.5.33
  • NES for Logback v1.2.15

Vulnerability Info

This Low-severity vulnerability is found in the ch.qos.logback:logback-core package in Logback versions up to and including 1.5.32.

HardenedObjectInputStream is the ObjectInputStream subclass that Logback's socket receivers, such as SimpleSocketServer and SimpleSSLSocketServer, use to read serialized logging events from the network. It overrides resolveClass and rejects any incoming class that isWhitelisted does not accept, so that only a known set of classes can be deserialized:

final static String[] JAVA_PACKAGES = new String[] { "java.lang", "java.util" };

@Override
protected Class<?> resolveClass(ObjectStreamClass anObjectStreamClass) throws IOException, ClassNotFoundException {
    String incomingClassName = anObjectStreamClass.getName();
    if (!isWhitelisted(incomingClassName)) {
        throw new InvalidClassException("Unauthorized deserialization attempt", anObjectStreamClass.getName());
    }
    return super.resolveClass(anObjectStreamClass);
}

private boolean isWhitelisted(String incomingClassName) {
    for (int i = 0; i < JAVA_PACKAGES.length; i++) {
        if (incomingClassName.startsWith(JAVA_PACKAGES[i]))
            return true;
    }
    for (String whiteListed : whitelistedClassNames) {
        if (incomingClassName.equals(whiteListed))
            return true;
    }
    return false;
}

The first loop authorizes a class by name prefix alone. Any class name that begins with java.lang or java.util passes the check before the explicit whitelist is consulted, so every serializable class in those two packages (and any name that merely starts with those characters) is accepted. A peer that can send or tamper with the serialized stream read by the socket server can therefore embed objects of java.lang and java.util classes that are not on any explicit whitelist, such as java.util.Hashtable or java.util.LinkedList, and readObject will instantiate them. The class-name whitelist that HardenedObjectInputStream is meant to enforce is bypassed for both packages. Exploitation requires that SimpleSocketServer or SimpleSSLSocketServer is running and reachable by the attacker.

Mitigation

Logback 1.2.x is End-of-Life and will not receive any updates to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a currently supported version of Logback.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• York Shen (finder)