GHSA-vmfg-rjjm-rjrj
CRITICALGHSA-vmfg-rjjm-rjrj is a critical-severity (CVSS 9.8) Deserialization of Untrusted Data vulnerability in ch.qos.logback:logback-classic. O3 Security confirms whether GHSA-vmfg-rjjm-rjrj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
QOS.ch Logback vulnerable to Deserialization of Untrusted Data
Blast Radius
ch.qos.logback:logback-classic☕ch.qos.logback:logback-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
QOS.ch Logback before 1.2.0 has a serialization vulnerability affecting the SocketServer and ServerSocketReceiver components. The RemoteStreamAppenderClient class in logback-classic and the SocketNode classes in logback-classic and logback-access allow data to be deserialized over a Java Socket, via an ObjectInputStream, without validating the data beforehand. When data is received from the Socket, to be logged, it is deserialized into Java objects.An attacker can exploit this vulnerability by sending malicious, serialized Java objects over the connection to the Socket, which may result in execution of arbitrary code when those objects are deserialized. Note that although logback-core is implicated by the Logback project here, the Sonatype Security Research team discovered that the vulnerability is actually present in the logback-classic and logback-access components. Versions prior to 1.2.0 are vulnerable, as stated in the advisory.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | ch.qos.logback:logback-classic | all versions | 1.2.0 |
| ☕Maven | ch.qos.logback:logback-core | all versions | 1.2.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ch.qos.logback:logback-classic. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update ch.qos.logback:logback-classic to 1.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vmfg-rjjm-rjrj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vmfg-rjjm-rjrj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vmfg-rjjm-rjrj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vmfg-rjjm-rjrj in your dependencies?
O3 detects GHSA-vmfg-rjjm-rjrj across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.