IBM Operational Decision Manager 9.6.0.0, 9.5.0.0, 8.11.1.0, 8.11.0.1, 8.12.0.1, 9.5.0.1, and 9.0.0.1 is vulnerable to SQL injection. An unauthenticated attacker can execute arbitrary SQL statements and leverage database functionality to write a web shell to the application web root, resulting in remote code execution.

Summary In BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPTCASEINSENSITIVEPROPERTIES)) rebuilds from this.beanProperties (the original, unfiltered map) instead of contextual.beanProperties, then overwrites the filtered map — restoring every property handleByNameInclusion had just removed. The ignored property becomes writable again.

Impact An application that both enables case-insensitive matching and relies on per-property @JsonIgnoreProperties to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).

Affected / Patched Fixed in 2.18.9, 2.21.5 and 3.1.4.

Severity / CWE Maintainer: minor. Reporter: Moderate. CWE-915.

Upstream fix FasterXML/jackson-databind#5962 (PR #5964, 0e1b0b2), milestone 3.1.4. Released 2026-06-04.

Credits Omkhar Arasaratnam (@omkhar) - finder.

Improper encoding of non-finite floating-point values during MapMessage JSON serialization in Apache Log4j API produces output that is not valid JSON. This issue affects Apache Log4j API versions 2.13.1 through 2.25.4 and version 2.26.0.

The fix for CVE-2026-34481 did not cover all code paths: when a MapMessage contains a non-finite IEEE 754 value (NaN, Infinity, or -Infinity), MapMessage.asJson() emits the corresponding bare token. RFC 8259 does not permit these tokens, so a conformant parser rejects the resulting document.

The defect is reachable only when both of the following conditions hold:

The application uses the message resolver

Description (as reported)

Summary

In Jetty 12.1.8, org.eclipse.jetty.util.URIUtil.canonicalPath() may leave dot-dot path segments unnormalized when a semicolon path parameter marker is followed by a slash and a dot segment.

A minimal example is:

/public;/../admin/secret

In my local reproduction, URIUtil.canonicalPath() returns:

/public/../admin/secret

instead of the expected normalized path:

/admin/secret

When Jetty's SecurityHandler.PathMapped is used to protect a path prefix such as /admin/, the non-normalized canonical path may not match the protected prefix. As a result, an unauthenticated request may bypass the configured path-based security constraint.

Tested Version

Jetty: 12.1.8 JDK: 17.0.18 Maven: 3.9.14

Maven artifacts used:

org.eclipse.jetty:jetty-server:12.1.8 org.eclipse.jetty:jetty-security:12.1.8 org.eclipse.jetty:jetty-session:12.1.8

Only confirmed Jetty 12.1.8 so far.

Minimal Reproduction

Starts a minimal Jetty server with the following security setup:

java SecurityHandler.PathMapped security = new SecurityHandler.PathMapped(); security.put("/admin/", Constraint.from("admin")); security.put("/", Constraint.ALLOWED); security.setAuthenticator(new BasicAuthenticator());

The test then sends requests with no Authorization header.

Observed result:

GET /admin/secret -> 401 GET /public;x/../admin/secret -> 200

The handler receives paths such as:

/public/../admin/secret

This suggests that the /admin/ security constraint is bypassed because PathMapped matching is performed against the non-normalized canonical path.

Suspected Root Cause

The suspected root cause is in URIUtil.canonicalPath().

The relevant logic is approximately:

java for (int i = 0; i < end; i++) { char c = encodedPath.charAt(i);

switch (c) { case ';': if (builder == null) { builder = new Utf8StringBuilder(encodedPath.length()); builder.append(encodedPath, 0, i); }

while (++i < end) { if (encodedPath.charAt(i) == '/') { builder.append('/'); break; } } break;

case '.': if (slash) normal = false; if (builder != null) builder.append(c); break; }

slash = c == '/'; }

String canonical = (builder != null) ? (onBadUtf8 == null ? builder.toCompleteString() : builder.takeCompleteString(onBadUtf8)) : encodedPath; return normal ? canonical : normalizePath(canonical);

For the input:

/public;/../admin/secret

when the outer loop reaches the semicolon:

i = 7 c = ';' slash = false normal = true

Inside case ';', the while (++i < end) loop advances i to the next character, which is already '/' for the empty path parameter form ";/".

The code then appends '/' to the canonical builder:

builder.append('/');

At this point, the canonical builder ends with '/':

/public/

However, the local variable c is still the old value ';', because c was read before entering the switch and is not updated when the inner loop advances i.

After leaving the switch, the loop updates the slash state using:

slash = c == '/';

Since c is still ';', slash becomes false.

On the next iteration, the scanner reaches '.', which is the first dot in the following "../" segment. Because slash is incorrectly false, this code does not run:

java if (slash) normal = false;

Therefore normal remains true, and canonicalPath() returns the canonical string directly instead of calling normalizePath(canonical).

The result is:

/public/../admin/secret

instead of:

/admin/secret

In short:

case ';' advances the scan position i and appends '/' to the canonical builder, but the loop tail still updates slash from the stale character c=';'. As a result, the following dot-dot segment is not detected as a path traversal segment.

More Precise Trigger Condition

The issue is not limited to a non-empty path parameter such as ";x".

The more precise trigger shape is:

;[^/]/.

Examples:

/public;/../admin/secret /public;x/../admin/secret /public;anything/../admin/secret /public;/./admin/secret

The minimal form is:

/public;/../admin/secret

because the semicolon is immediately followed by '/', so the inner while loop reaches '/' on its first increment.

Potential Minimal Fix Direction

A minimal fix would be to ensure that, when case ';' consumes input until '/' and appends '/' to the canonical builder, the slash state reflects the last effective character in the canonical path.

For example, conceptually:

java case ';': if (builder == null) { builder = new Utf8StringBuilder(encodedPath.length()); builder.append(encodedPath, 0, i); }

while (++i < end) { if (encodedPath.charAt(i) == '/') { builder.append('/'); slash = true; break; } } continue;

The important part is to avoid the loop tail from overwriting slash using the stale c value:

slash = c == '/';

In other words, slash should represent the last effective character appended to the canonical builder, not the original input character read before case ';' advanced i.

Summary UnwrappedPropertyHandler.processUnwrapped() replays the buffered JSON for a @JsonUnwrapped property by iterating its properties and calling prop.deserializeAndSet() with no prop.visibleInView(ctxt.getActiveView()) guard — the exact guard processUnwrappedCreatorProperties() received in the #5971 / GHSA-rcqc-6cw3-h962 fix, and the guard BeanDeserializer.deserializeWithUnwrapped applies to directly-matched properties. As a result, a property annotated with both @JsonView(PrivilegedView.class) and @JsonUnwrapped is written from attacker JSON even when deserializing under a more-restrictive active view.

Correction to the original framing (runtime-verified): the gap is NOT a per-field inner @JsonView (the unwrapped sub-object's own BeanDeserializer gates inner fields correctly). The unchecked gate is the view of the unwrapped CONTAINER property.

Intent proof (runtime, 2.x HEAD 21dd70dd and 3.x HEAD 7a5939d6) An @JsonView(AdminView) property that is NOT @JsonUnwrapped → null under PublicView (correctly gated). The identical property WITH @JsonUnwrapped → fully populated (bypass). The fix the creator path already received, not applied to the regular-property method.

Impact — write-side mass-assignment / privilege escalation @JsonView is commonly used as a write-side authorization guard: a public endpoint binds the body under readerWithView(PublicView.class) and groups privileged state in a nested object whose container property is @JsonView(AdminView). When that property is @JsonUnwrapped, an untrusted caller mass-assigns it. PoC: a self-service registration where AccountFlags{role,approved,creditBalance} is @JsonView(AdminView) @JsonUnwrapped; attacker JSON {role:ADMIN,approved:true,creditBalance:1000000} under PublicView binds all three → approved admin with arbitrary balance. The failing gate is a WRITE gate, hence integrity-high (C:N/I:H/A:N); no worse than the C:L/I:L parent and arguably higher as @JsonView-as-write-guard is the exact use case #5971/#5969 defended.

Affected - com.fasterxml.jackson.core:jackson-databind 2.x: confirmed bypass at 21dd70dd (== released 2.21.4 / 2.22.0 line; includes the #5973 backport). DEFAULTVIEWINCLUSION default=true. - tools.jackson.core:jackson-databind 3.x: confirmed bypass at HEAD 7a5939d6 (latest 3.x). DEFAULTVIEWINCLUSION default=false → the stock-config repro is the common shape where privileged inner fields are individually @JsonView(PublicView) and the developer relies on the container @JsonView(AdminView); the 3.x PoC mass-assigns role/approved/creditBalance under PublicView. (The other simultaneous report's PoC was reportedly fixed on 3.x; this distinct container-property path is not.)

Additive variants (runtime-confirmed both branches; all closed by the same one-line guard) - nested @JsonUnwrapped (unwrapped-in-unwrapped) — recursive bypass. - merge / readerWithView(...).withValueToUpdate(...) (PATCH/partial-update) — bypass; non-unwrapped merge control gates correctly. - builder-based deserializer (@JsonDeserialize(builder=...)) — BuilderBasedDeserializer routes through the same processUnwrapped. - Honest non-findings: read-side serialization correctly honors views (no leak); @JsonAnySetter+view and @JsonTypeInfo+@JsonUnwrapped are separate/unsupported behaviors, not this bug.

Fix Add prop.visibleInView(ctxt.getActiveView()) (when MapperFeature.DEFAULTVIEWINCLUSION/active-view applies) to the processUnwrapped() property loop, mirroring processUnwrappedCreatorProperties(). One change closes the impact PoC + all three variants across BeanDeserializer and BuilderBasedDeserializer. Full runnable PoCs (2.x + 3.x) + variant harnesses available on request.

Path-traversal vulnerability in QOS.CH Sarl Logback-classic on Java (logback-classic module) allows path-traversal vulnerability. More specifically, an MDC-based discriminator value flows unsanitized into a nested FileAppender path, letting an attacker who influences that MDC value (e.g. via an HTTP header) create and append log files outside the intended directory.

This issue affects Logback-classic: from 0.9.14 through 1.6.2.

IBM Operational Decision Manager 8.11.0.1, 8.11.1.0, 8.12.0.1, and 9.0.0.1 is vulnerable to cross-site scripting. This vulnerability allows an unauthenticated attacker to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, a malicious user can send a request using a specially crafted URL that can lead to a directory traversal attack.

Specifically, an application is vulnerable if Reactor Netty HTTP Server is configured to serve static resources.

In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition.

Specifically, an application is vulnerable if Reactor Netty HTTP Server built-in integration with Micrometer is enabled.

In Spring Boot versions 2.7.0 - 2.7.17, 3.0.0-3.0.12 and 3.1.0-3.1.5, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition.

Specifically, an application is vulnerable when all of the following are true:

the application uses Spring MVC or Spring WebFlux org.springframework.boot:spring-boot-actuator is on the classpath

IBM Operational Decision Manager 8.10.3, 8.10.4, 8.10.5.1, 8.11, 8.11.0.1, 8.11.1 and 8.12.0.1 is susceptible to remote code execution attack via JNDI injection when passing an unchecked argument to a certain API. IBM X-Force ID: 279145.

IBM Operational Decision Manager 8.10.3 could allow a remote authenticated attacker to execute arbitrary code on the system, caused by an unsafe deserialization. By sending specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code in the context of SYSTEM. IBM X-Force ID: 279146.