The version of Atlassian Jira Service Management Data Center and Server (Jira Service Desk) running on the remote host is affected by a vulnerability as referenced in the JSDSERVER-16835 advisory.

  - The CBOR parser in FasterXML jackson-dataformats-binary never invokes     StreamReadConstraints.validateNameLength() when decoding JSON object property names, so the maxNameLength     limit is not enforced for this format. CBORParser._decodeLongerName() decodes a definite-length property     name with no length check, and CBORParser._decodeChunkedName() delegates to the value-oriented
    _finishChunkedText() routine, which validates maxStringLength rather than maxNameLength. An attacker who     can have a CBOR document parsed may therefore embed a single property name of unbounded length; the parser     buffers the whole name in memory before returning it, whatever maxNameLength is configured to. Because     StreamReadConstraints.maxDocumentLength is also disabled by default, nothing else bounds the name under     default settings, so the only limits are the attacker's upload capacity and available heap, leading to     memory exhaustion and denial of service. No privileges beyond the ability to submit data to a parsing     endpoint are required, and exploitation needs only that the bytes reach CBORFactory parsing, directly or     through an ObjectMapper configured with the CBOR module. jackson-core's own JSON parsers enforce     maxNameLength incrementally during name decoding; this gap is specific to the binary formats.
    maxNameLength and validateNameLength were introduced in jackson-core 2.16.0, so releases before 2.16.0 do     not contain the constraint that is left unenforced. This issue is tracked together with the Smile parser     defect in the same vendor advisory, GHSA-3v8f-v6vx-fmrm, which covers both binary formats. The CBOR parser     defect (jackson-dataformats-binary issue #725) is CVE-2026-68495; the Smile parser defect (issue #726) is     assigned CVE-2026-68496. (CVE-2026-68495)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The version of Atlassian Confluence Server running on the remote host is affected by a vulnerability as referenced in the CONFSERVER-104515 advisory.

  - The CBOR parser in FasterXML jackson-dataformats-binary never invokes     StreamReadConstraints.validateNameLength() when decoding JSON object property names, so the maxNameLength     limit is not enforced for this format. CBORParser._decodeLongerName() decodes a definite-length property     name with no length check, and CBORParser._decodeChunkedName() delegates to the value-oriented
    _finishChunkedText() routine, which validates maxStringLength rather than maxNameLength. An attacker who     can have a CBOR document parsed may therefore embed a single property name of unbounded length; the parser     buffers the whole name in memory before returning it, whatever maxNameLength is configured to. Because     StreamReadConstraints.maxDocumentLength is also disabled by default, nothing else bounds the name under     default settings, so the only limits are the attacker's upload capacity and available heap, leading to     memory exhaustion and denial of service. No privileges beyond the ability to submit data to a parsing     endpoint are required, and exploitation needs only that the bytes reach CBORFactory parsing, directly or     through an ObjectMapper configured with the CBOR module. jackson-core's own JSON parsers enforce     maxNameLength incrementally during name decoding; this gap is specific to the binary formats.
    maxNameLength and validateNameLength were introduced in jackson-core 2.16.0, so releases before 2.16.0 do     not contain the constraint that is left unenforced. This issue is tracked together with the Smile parser     defect in the same vendor advisory, GHSA-3v8f-v6vx-fmrm, which covers both binary formats. The CBOR parser     defect (jackson-dataformats-binary issue #725) is CVE-2026-68495; the Smile parser defect (issue #726) is     assigned CVE-2026-68496. (CVE-2026-68495)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:4394-1 advisory.

    - CVE-2026-18401: Number Length Constraint Bypass in Async Parser Can Lead to Potential Processing Time     Issues       (bsc#1273856).
    - CVE-2026-68494: Async parser maxNumberLength bypass via chunked digit accumulation (bsc#1273857).
    - CVE-2026-68495: Ensure maxNameLength limit enforced for CBOR parser (bsc#1282639).
    - CVE-2026-68496: Ensure maxNameLength limit enforced for Smile parser (bsc#1282640).
    - CVE-2026-68498: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641).
    - CVE-2026-89407: Optimize NumberInput.looksLikeValidNumber (bsc#1282645).
    - CVE-2026-89425: `UTF8DataInputJsonParser._reportInvalidToken()`lacks `maxErrorTokenLength` limit, which     allows for       unbounded `StringBuilder` growth and can lead to a DoS when malformed tokens are processed     (bsc#1282505).

    Changes for jackson-annotations:

    - Update to 2.18.11

    Changes for jackson-bom:

    - Update to 2.18.11

    Changes for jackson-core:

    - Update to 2.18.11
     * #1649: Optimize NumberInput.looksLikeValidNumber (bsc#1282645,      CVE-2026-89407)
     * #1698: UTF8DataInputJsonParser does not honor      maxErrorTokenLength when reporting an unrecognized token      (bsc#1282505, CVE-2026-89425)
     * #1642: Fix maxDocumentLength bypass in async parser      single-feedInput() case [GHSA-2c4j-63jj-9fqr]
     * #1643: Enforce maxNameLength incrementally in      ReaderBasedJsonParser (bsc#1282641, CVE-2026-68498)      of async parser (bsc#1273857, CVE-2026-68494)      non-blocking (async) parser (bsc#1273856, CVE-2026-18401)

    Changes for jackson-databind:

    - Update to 2.18.11
     * #6185: Bracket unresolved IPv6 host name in InetSocketAddress      serialization
     * #6203: Prevent unbounded growth of type id cache in      TypeDeserializer (bsc#1282491, CVE-2026-91776)
     * #6204: Avoid quadratic forward-reference resolution in      Collection/Map deserializers (bsc#1282492, CVE-2026-91777)
     * #6099: Resolve classes without initialization in      TypeFactory.findClass()
     * #6116: Reject non-ASCII digits in InetAddress literal validation
     * #6127: Add StreamReadConstraints number len constraint to      javax.xml.datatype.XMLGregorianCalendar and      javax.xml.datatype.Duration (bsc#1280125, CVE-2026-68497)
     * #6129: Limit the supported URL schemes for java.nio.file.Path      deserialization (bsc#1277883, CVE-2026-19032)
     * #6156: Add java.lang.Comparable in set of unsafe polymorphic      base types (bsc#1278008, CVE-2026-83557)
     * #6165: Apply number length limits to BigDecimal/BigInteger/      /Double/Float Map keys

    Changes for jackson-dataformat-xml:

    - Update to 2.18.11
     * Fix build to avoid past-JDK-8 bytecode generation
     * #891: Enforce StreamReadConstraints.maxNestingDepth in      FromXmlParser

    Changes for jackson-dataformats-binary:

    - Update to 2.18.11
     * #783: (protobuf) Support StreamReadConstraints.maxDocumentLength      in ProtobufParser
     * #785: (avro) Support StreamReadConstraints.maxDocumentLength and      maxTokenCount in Avro parser
     * #803: (ion) Support StreamReadConstraints.maxNestingDepth in Ion      parser (partial fix for #358)
     * #805: (ion) Support StreamReadConstraints.maxDocumentLength in      Ion parser (partial fix for #358)
     * #725: (cbor) Ensure maxNameLength limit enforced for CBOR parser      (bsc#1282639, CVE-2026-68495)
     * #726: (smile) Ensure maxNameLength limit enforced for Smile      parser (bsc#1282640, CVE-2026-68496)
     * #727: (cbor) CBORParser.nextFieldName(SerializableString)      confuses 5-bit length marker 23 with 24 ('1-byte length suffix      follows')
     * #728: (cbor) CBORParser.nextFieldName(SerializableString)      consumes Object entry slot twice on fast-path miss, truncating      definite-length Objects
     * #733: (cbor) Long `String`s not added to 'stringref' reference      table, breaking following references
     * #735: (cbor) 'stringref' property-name paths pass 5-bit length      marker instead of actual length to shouldReferenceString()
     * #736: (cbor) Long Object property names added to 'stringref'      reference table twice

    Changes for jackson-modules-base:

    - Update to 2.18.11

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - The CBOR parser in FasterXML jackson-dataformats-binary never invokes     StreamReadConstraints.validateNameLength() when decoding JSON object property names, so the maxNameLength     limit is not enforced for this format. CBORParser._decodeLongerName() decodes a definite-length property     name with no length check, and CBORParser._decodeChunkedName() delegates to the value-oriented
    _finishChunkedText() routine, which validates maxStringLength rather than maxNameLength. An attacker who     can have a CBOR document parsed may therefore embed a single property name of unbounded length; the parser     buffers the whole name in memory before returning it, whatever maxNameLength is configured to. Because     StreamReadConstraints.maxDocumentLength is also disabled by default, nothing else bounds the name under     default settings, so the only limits are the attacker's upload capacity and available heap, leading to     memory exhaustion and denial of service. No privileges beyond the ability to submit data to a parsing     endpoint are required, and exploitation needs only that the bytes reach CBORFactory parsing, directly or     through an ObjectMapper configured with the CBOR module. jackson-core's own JSON parsers enforce     maxNameLength incrementally during name decoding; this gap is specific to the binary formats.
    maxNameLength and validateNameLength were introduced in jackson-core 2.16.0, so releases before 2.16.0 do     not contain the constraint that is left unenforced. This issue is tracked together with the Smile parser     defect in the same vendor advisory, GHSA-3v8f-v6vx-fmrm, which covers both binary formats. The CBOR parser     defect (jackson-dataformats-binary issue #725) is CVE-2026-68495; the Smile parser defect (issue #726) is     assigned CVE-2026-68496. (CVE-2026-68495)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
367875	Atlassian Jira Service Management Data Center and Server 10.3.x < 10.3.26 / 11.3.x < 11.3.11 (JSDSERVER-16835)	Nessus	Misc.	10/20/2026	10/20/2026	high
368968	Atlassian Confluence 9.1.x < 9.2.26 / 9.3.x < 10.2.19 / 11.0.0 (CONFSERVER-104515)	Nessus	CGI abuses	10/21/2026	10/21/2026	high
351412	SUSE SLED15: jackson-annotations / jackson-core / jackson-databind / etc (SUSE-SU-2026:4394-1)	Nessus	SuSE Local Security Checks	9/30/2026	9/30/2026	high
362607	Linux Distros Unpatched Vulnerability : CVE-2026-68495	Nessus	Misc.	10/2/2026	10/19/2026	high

Detections

Analytics

Plugins Search

high

high

high

high