CGA-WWPH-FXQ5-RJ2M: camunda-zeebe-8.6 Chainguard
Unknown
Published Date unknownLast modified Date unknown
Status not reported
The data service did not report a status for this record. Only the available sections are shown.Vulnerability summary
CGA-WWPH-FXQ5-RJ2M is a vulnerability in camunda-zeebe-8.6 Chainguard with no CVSS score yet.
Priority
Insufficient evidence
No CVSS vector published; no exploitation reported by the 5 checked sources
Source freshness unavailable
How is this decided?CVSS score
Not scored
010
No CVSS score recordedEPSS scoreNot scoredRisk metrics not yet published.
KEVNot listedNot listed by any tracked catalog.
RansomwareNot flaggedNo ransomware use recorded.
Public exploits0No public exploits recorded
Advisory lineage
Upstream 0 · Downstream 0 · Related 1Timeline
No timeline events recorded.
Description
No description has been published for this record.
CVSS metrics
Risk metrics not yet published.
EPSS trend
No EPSS score has been published for this record yet.
Known exploited
Compare KEV catalogs
CISA KEVNot in the CISA KEV catalog.
ENISA CNWNot in the ENISA CNW catalog.
CIRCLNot in the CIRCL catalog.
Public exploits
0 foundNo public exploits indexed.
Weaknesses
CWE · root causeNo weakness data has been published for this record.
Affected systems
Version check
Known conditions: not stated in public data.
Chainguard18 products
- camunda-zeebe-8.6< 8.6.29-r2
- camunda-zeebe-8.6-compat< 8.6.29-r2
- camunda-zeebe-8.7< 8.7.16-r1
- camunda-zeebe-8.7-compat< 8.7.16-r1
- kayenta-2025.0< 2025.0.8-r3
- kayenta-2025.1< 2025.1.5-r3
- kayenta-2025.2< 2025.2.2-r3
- kayenta-fips-2025.0< 2025.0.8-r3
- kayenta-fips-2025.1< 2025.1.6-r0
- kayenta-fips-2025.2< 2025.2.2-r3
- seata< 2.5.0-r3
- seata-namingserver< 2.5.0-r3
- seata-namingserver-oci-entrypoint< 2.5.0-r3
- seata-openjdk-17-compat< 2.5.0-r3
- seata-openjdk-21-compat< 2.5.0-r3
- seata-openjdk-8-compat< 2.5.0-r3
- seata-server< 2.5.0-r3
- seata-server-oci-entrypoint< 2.5.0-r3
1 vendor · 18 products
References
0 linksNo references have been published for this record.
Related vulnerabilities
PrioritiseCVE-2026-91777fasterxml · jackson-databind +700 morejackson-databind: quadratic forward-reference completion in Collection and Map deserializersForward-reference completion for @JsonIdentityInfo object IDs in FasterXML jackson-databind performs a linear scan of the pending-reference accumulator for every resolved ID. The affected paths are CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference() and the equivalent implementation in MapDeserializer. When a document first creates N unresolved object-ID references in an identity-enabled collection or map and then defines those same IDs in reverse order, completion performs on the order of N * (N + 1) / 2 identity comparisons, so a shallow document whose size grows linearly causes quadratic CPU work during deserialization. The reporter instrumented equals() calls on the ID class and measured exactly 2,003,000 comparisons at N = 2,000, against zero comparisons in the pending-reference lookup path for an equally sized control in which every reference was already resolved. The input requires no deep nesting and no syntactically unusual JSON. Exploitation requires an application that deserializes attacker-influenced JSON into an identity-enabled collection or map. The fix replaces the repeated linear lookup with a keyed pending-reference structure.CVSS7.5HighEPSS0.49%PrioritiseCVE-2026-91776fasterxml · jackson-databind +709 morejackson-databind: unbounded growth of the type id cache in TypeDeserializerBase retains every unknown raw type IDTypeDeserializerBase._findDeserializer() in FasterXML jackson-databind caches the resolved deserializer under the raw, attacker-supplied type ID. When name-based polymorphism is configured with a fallback, for example @JsonTypeInfo(use = Id.NAME, defaultImpl = ...), every distinct unrecognized type ID resolves to the same fallback deserializer but is retained as its own key in the _deserializers map. That map has no configurable bound and lives for the lifetime of the type deserializer, so an attacker who can repeatedly supply fresh unknown type IDs causes monotonic memory retention across requests. The reporter observed 10,000 retained entries from 10,000 distinct unknown IDs, against a single entry for a control that repeated one unknown ID the same number of times, isolating attacker-controlled key cardinality from request volume. Exploitation requires an application that enables name-based polymorphism with a defaultImpl or equivalent fallback, accepts attacker-influenced type IDs, and reuses a long-lived ObjectMapper across requests. The fix stops caching fallback resolutions for unrecognized IDs and bounds both the number of cached entries and the length of a cacheable type ID.CVSS7.5HighEPSS0.49%PrioritiseCVE-2026-89425fasterxml · jackson-core +451 morejackson-core: UTF8DataInputJsonParser._reportInvalidToken() does not honor maxErrorTokenLength, allowing unbounded StringBuilder growthUTF8DataInputJsonParser._reportInvalidToken() in FasterXML jackson-core builds the offending-token text for its error message by appending Java identifier characters to a StringBuilder in a loop that has no upper bound. Unlike the three sibling parser implementations, including UTF8StreamJsonParser, it never consults ErrorReportConfiguration.getMaxErrorTokenLength() (default 256). A malformed token supplied to a parser created through JsonFactory.createParser(DataInput) is therefore accumulated in full. No StreamReadConstraints setting mitigates this: maxDocumentLength cannot be applied to DataInput sources at all, and maxStringLength does not cover this path because the accumulation bypasses ReadConstrainedTextBuffer. The reporter measured a 20,000,109-character exception message from a 20-million-character malformed token on the DataInput path, against 367 characters for identical input on the InputStream path. Scaling the payload drives the StringBuilder, which also incurs byte-to-char expansion and internal array doubling, to many times the raw payload size and can trigger OutOfMemoryError for the whole JVM. UTF8DataInputJsonParser was introduced in 2.8.0 together with createParser(DataInput); releases before 2.8.0 do not contain the affected class.CVSS7.5HighEPSS0.53%PrioritiseCVE-2026-89407fasterxml · jackson-core +339 morejackson-core: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber() enables ReDoSNumberInput.looksLikeValidNumber() in FasterXML jackson-core pre-validates "stringified numbers" with two regular expressions: PATTERN_FLOAT ([+-]?[0-9]*[\.]?[0-9]+([eE][+-]?[0-9]+)?), present since 2.17.0, and PATTERN_FLOAT_TRAILING_DOT, added in 2.17.2. PATTERN_FLOAT places adjacent quantifiers over the same character class -- an optional [0-9]* run, an optional dot, then a required [0-9]+ run -- so input that ultimately fails to match forces Java's backtracking engine to retry every possible split point of the digit run.
Matching cost therefore grows with the square of the input length.
An attacker who can supply JSON that an application deserializes into a numeric target type reaches this method through jackson-databind's default String-to-number coercion (StdDeserializer and NumberDeserializers for BigDecimal, BigInteger, Double and Float).
Because StreamReadConstraints.maxStringLength defaults to 20,000,000 characters, no constraint bounds the input before it reaches the regex.
Testing by the reporter confirmed O(n^2) growth across five consecutive input-size doublings, with a single 160,000-character string consuming roughly 74 seconds in one call; a small number of concurrent requests of ordinary body size can therefore exhaust a server's request-handling thread pool.
The affected method does not exist before 2.17.0, so 2.16.x and earlier releases are not affected.
The fix replaces both regular expressions with a hand-rolled single-pass scan.CVSS7.5HighEPSS0.63%PrioritiseCVE-2026-68497fasterxml · jackson-databind +602 morejackson-databind: unbounded numeric parse in Duration and XMLGregorianCalendar deserialization allows CPU denial of servicejackson-databind binds a JSON string to a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field by passing the raw string verbatim to DatatypeFactory.newDuration(value) or newXMLGregorianCalendar(value) in CoreXMLDeserializers.Std._deserialize. These deserializers are registered by default with no opt-in, so a plain ObjectMapper or JsonMapper with no polymorphic typing and no special configuration reaches this path. The XML Schema lexical grammar permits numeric components of arbitrary length, which the JDK materializes through the native BigInteger(String) and BigDecimal(String) constructors, both quadratic in digit count. Because the digits sit inside a JSON string token rather than a JSON number token, jackson-core's StreamReadConstraints.maxNumberLength guard never applies; jackson's own NumberDeserializers call validateIntegerLength or validateFPLength before parsing a stringified number, but the XML datatype deserializer omits that pre-check. An unauthenticated attacker can therefore submit a single request of a few megabytes, such as a Duration value consisting of the letter P followed by several million digits and the letter Y, and force tens of seconds to several minutes of single-threaded CPU work; a handful of concurrent requests can saturate a server's worker threads. This affects com.fasterxml.jackson.core:jackson-databind from 2.0.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2.CVSS7.5HighEPSS0.63%RoutineCVE-2026-83557fasterxml · jackson-databind +608 morejackson-databind omits java.lang.Comparable from DefaultBaseTypeLimitingValidator's unsafe base typesDefaultBaseTypeLimitingValidator is the PolymorphicTypeValidator applied automatically whenever @JsonTypeInfo is used without an explicitly configured custom validator. It denies polymorphic resolution only for a fixed set of "unsafe base types", and its isSafeSubType method returns true unconditionally for every base type outside that set. java.lang.Comparable was absent from the list despite being implemented by a very large fraction of JDK and application classes, comparable in breadth to java.io.Serializable, which is on the list for that reason. An application declaring an @JsonTypeInfo-annotated property or class with Comparable as its base type, and no custom PolymorphicTypeValidator, will accept a type identifier for essentially any class implementing Comparable. This yields an attacker-controlled object instantiation primitive; a demonstrated case constructs a java.io.File for an arbitrary attacker-chosen path, which becomes path-traversal-adjacent if the application subsequently calls path-sensitive methods on the value. No class implementing Comparable has been identified that yields code execution through deserialization alone. Global Default Typing via activateDefaultTyping is not affected, because that method structurally requires an explicit PolymorphicTypeValidator argument. This affects com.fasterxml.jackson.core:jackson-databind from 2.11.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2.CVSS5.6MediumEPSS0.72%