Forum Discussion

vivekkrraiii's avatar
vivekkrraiii
New Contributor
1 day ago

Recommended remediation for jackson-coreutils CVEs while retaining Swagger 1.x support

Title: Recommended remediation for jackson-coreutils CVEs while retaining Swagger 1.x support

Hi maintainers,

We use Swagger Parser 2.1.23 on Java 8 and may need to retain Swagger 1.x compatibility. Its legacy compatibility dependency chain brings in jackson-coreutils 2.0, flagged for CVE-2026-86513, CVE-2026-86511, and CVE-2026-86321.

In isolated Java 8 parser tests, excluding jackson-coreutils caused Swagger 1.2 conversion to fail with:
NoClassDefFoundError: com/github/fge/jackson/jsonpointer/JsonPointer

Our representative Swagger 2 and OpenAPI 3 imports still passed. Removing the legacy compatibility stack instead caused Swagger 1.2 documents to be rejected.

Is there a supported release, replacement dependency, or recommended mitigation that addresses these findings while preserving Swagger 1.x support and Java 8 compatibility?

We have not confirmed exploitability of these CVEs through Swagger Parser. Any guidance on their applicability to its parsing/conversion paths would also be appreciated.

Related upstream reports:

Thank you.

4 Replies

  • > The traditional path would be remediating the vulns at source, with a contribution to jackson-coreutils, which consuming libraries such as swagger-compat-spec-parser can pull in via a corresponding pull request targeting the v1 branch.

    Okay, thanks for the clarification, will look into this.

    Our use case is an enterprise product with customers running long-lived legacy integrations. The provider onboarding functionality allows customers to import a Swagger definition from a supplied URL.

    We do not actively recommend or develop against Swagger 1.x, but because the compatibility parser is currently included transitively, existing customers may be relying on it. At this point, we cannot safely confirm that no customer imports Swagger 1.x definitions.

    If Swagger 1.2 must remain supported, we understand that the appropriate upstream path is to remediate jackson-coreutils first and then update the dependency in the Swagger Parser v1 branch.

    Thanks for your help.

  • Thanks for the clarification.

    So looking on Maven

    https://mvnrepository.com/artifact/io.swagger/swagger-compat-spec-parser/versions

    This would be the 1.x line of the swagger-parser repo

    https://github.com/swagger-api/swagger-parser/tree/v1

    The traditional path would be remediating the vulns at source, with a contribution to jackson-coreutils, which consuming libraries such as swagger-compat-spec-parser can pull in via a corresponding pull request targeting the v1 branch.

    > I would also appreciate guidance on whether Swagger 1.2 compatibility still has a supported migration path.

    I do not know of any other than migrate to a newer version of Swagger now OpenAPI specification, especially as the swagger ecosystem rolls out Jackson 3, I don't believe you'll be able to support Jackson 2/3 in the same project.

    Could I be nosy and ask the use case for supporting Swagger 1.2? I joined the ecosystem at Swagger 2.0 back in early 2015 and have never used 1.2!

  • Thank you for the clarification. You’re correct that the documentation does not state that Swagger Parser 2.x officially supports Swagger Specification 1.x. Our resolved dependency tree is:

    io.swagger.parser.v3:swagger-parser:2.1.23
    └── swagger-parser-v2-converter:2.1.23
    ├── io.swagger:swagger-parser:1.0.71
    └── swagger-compat-spec-parser:1.0.71
    ├── json-schema-validator:2.2.14
    │ └── json-schema-core:1.2.14
    │ └── jackson-coreutils:2.0
    └── json-patch:1.13
    └── jackson-coreutils:2.0

    Our application also calls the older io.swagger.parser.SwaggerParser API. In an isolated Java 8 test, a Swagger 1.2 document was converted successfully with these dependencies. Removing jackson-coreutils caused the legacy conversion to fail with:

    NoClassDefFoundError: com/github/fge/jackson/jsonpointer/JsonPointer

    Therefore, our legacy Swagger support comes from the transitive Parser 1.x compatibility components, rather than documented native support in Parser 2.x.

    Given that the vulnerable dependency is introduced through swagger-compat-spec-parser:1.0.71, which repository and branch should this be reported against? Should the remediation be made in Swagger Parser’s compatibility module, or does it need to be handled exclusively by the jackson-coreutils project?

    I would also appreciate guidance on whether Swagger 1.2 compatibility still has a supported migration path.

  • Hiya, welcome to the community.

    I have also replied on reddit, but have copied my reply here as well.

    Swagger Parser 2.1.23 is a 2 year old release.

    https://github.com/swagger-api/swagger-parser/releases/tag/v2.1.23

    Going by the docs, Swagger Parser 2.1.0+ supports OpenAPI 3.1 with Swagger Parser 1.x line having support for Swagger 1.0 / OpenAPI 2.0.

    We are working on the Jackson 3 upgrade across the ecosystem, but most likely won't be back-porting to the 1.x swagger parser line. We have accepted PR's to this branch, so I would recommend testing out your solution in a fork, and proposing the changes back, however I would also raise the issue on the GitHub repository, as you may get community support from others.

    Can you confirm where in the documentation or code, it shows that there is Swagger Spec 1.x compat in Swagger Parser 2.x line?