📦 Bump versions of multiple dependencies to address vulnerabilities #82
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Lineaje has automatically created this pull request to resolve the following CVEs:
and older unsupported versions, it is possible for a user to
provide malicious input to cause the insertion of additional
log entries. This is a follow-up to CVE-2021-22096 that
protects against additional types of input and in more places
of the Spring Framework codebase.
and older unsupported versions, it is possible for a user to
provide malicious input to cause the insertion of additional
log entries.
correctly resolve annotations on methods within type
hierarchies with a parameterized super type with unbounded
generics. This can be an issue if such annotations are used
for authorization decisions. Your application may be affected
by this if you are using Spring Security's
@EnableMethodSecurity feature. You are not affected by this
if you are not using @EnableMethodSecurity or if you do not
use security annotations on methods in generic superclasses
or generic interfaces. This CVE is published in conjunction
with CVE-2025-41248 https://spring.io/security/cve-2025-41248
.
2.13.x before 2.13.1 allows attackers to cause a denial of
service (2 GB transient heap usage per read) in uncommon
situations involving JsonNode JDK serialization.
Data Processor. jackson-databind allows a Java stack overflow
exception and denial of service via a large depth of nested
objects.
2.13.x before 2.13.4.2 resource exhaustion can occur because
of a lack of a check in primitive value deserializers to
avoid deep wrapper array nesting, when the
UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. This was
patched in 2.12.7.1, 2.13.4.2, and 2.14.0. Commits that
introduced vulnerable code are
FasterXML/jackson-databind@d499f2e,
FasterXML/jackson-databind@0e37a39,
and
FasterXML/jackson-databind@7ba9ac5.
Fix commits are
FasterXML/jackson-databind@cd09097
and
FasterXML/jackson-databind@d78d00e.
The
2.13.4.1release does fix this issue, however it alsoreferences a non-existent jackson-bom which causes build
failures for gradle users. See
FasterXML/jackson-databind#3627 (comment)
for details. This is fixed in
2.13.4.2which is listed inthe advisory metadata so that users are not subjected to
unnecessary build failures
before 2.13.4, resource exhaustion can occur because of a
lack of a check in BeanDeserializer._deserializeFromArray to
prevent use of deeply nested arrays. This issue can only
happen when the
UNWRAP_SINGLE_VALUE_ARRAYSfeature isexplicitly enabled.
an input file and it has deeply nested data, Jackson could
end up throwing a StackoverflowError if the depth is
particularly large. ### Patches jackson-core 2.15.0 contains
a configurable limit for how deep Jackson will traverse in an
input document, defaulting to an allowable depth of 1000.
Change is in
FasterXML/jackson-core#943.
jackson-core will throw a StreamConstraintsException if the
limit is reached. jackson-databind also benefits from this
change because it uses jackson-core to parse JSON inputs. ###
Workarounds Users should avoid parsing input files from
untrusted sources.
JsonLocation._appendSourceDescmethod allows up to 500bytes of unintended memory content to be included in
exception messages. When parsing JSON from a byte array with
an offset and length, the exception message incorrectly reads
from the beginning of the array instead of the logical
payload start. This results in possible information
disclosure in systems using pooled or reused buffers,
like Netty or Vert.x. ### Details The vulnerability affects
the creation of exception messages like:
<br>JsonParseException: Unexpected character ... at [Source:<br>(byte[])...]WhenJsonFactory.createParser(byte[] data,<br>int offset, int len)is used, and an error occurs whileparsing, the exception message should include a snippet from
the specified logical payload. However, the method
_appendSourceDescignores theoffset, and always startsreading from index
0. If the buffer contains residualsensitive data from a previous request, such as credentials
or document contents, that data may be exposed if the
exception is propagated to the client. The issue particularly
impacts server applications using: * Pooled byte buffers
(e.g., Netty) * Frameworks that surface parse errors in HTTP
responses * Default Jackson settings (i.e.,
INCLUDE_SOURCE_IN_LOCATIONis enabled) A documentedreal-world example is
CVE-2021-22145
in Elasticsearch, which stemmed from the same root cause. ###
Attack Scenario An attacker sends malformed JSON to a service
using Jackson and pooled byte buffers (e.g., Netty-based HTTP
servers). If the server reuses a buffer and includes the
parser’s exception in its HTTP 400 response, the attacker
may receive residual data from previous requests. ### Proof
of Concept
java byte[] buffer = new byte[1000];<br>System.arraycopy("SECRET".getBytes(), 0, buffer, 0, 6);<br>System.arraycopy("{ \"bad\": }".getBytes(), 0, buffer, 700,<br>10); JsonFactory factory = new JsonFactory(); JsonParser<br>parser = factory.createParser(buffer, 700, 20);<br>parser.nextToken(); // throws exception // Exception message<br>will include "SECRET"### Patches This issue was silentlyfixed in jackson-core version 2.13.0, released on September
30, 2021, via PR
#652.
All users should upgrade to version 2.13.0 or later. ###
Workarounds If upgrading is not immediately possible,
applications can mitigate the issue by: 1. Disabling
exception message exposure to clients — avoid returning
parsing exception messages in HTTP responses. 2. Disabling
source inclusion in exceptions by setting:
java<br>jsonFactory.disable(JsonFactory.Feature.INCLUDE_SOURCE_IN_LOCATION);<br>This prevents Jackson from embedding any source contentin exception messages, avoiding leakage. ### References
Pull Request #652 (Fix
implementation)
CVE-2021-22145 (Elasticsearch exposure of this
flaw)
integer truncation issue when processing malicious XSLT
stylesheets. This can be used to corrupt Java class files
generated by the internal XSLTC compiler and execute
arbitrary Java bytecode. A fix for this issue was published
in September 2022 as part of an anticipated 2.7.3 release.
prior to 2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API,
are vulnerable to an issue where a private key may be
disclosed in log files when generating an XML Signature and
logging with debug level is enabled. Users are recommended to
upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this
issue.
prior to 2.2.3 and 2.1.7 are vulnerable to an issue where the
"secureValidation" property is not passed correctly when
creating a KeyInfo from a KeyInfoReference element. This
allows an attacker to abuse an XPath Transform to extract any
local .xml files in a RetrievalMethod element.
You can merge this PR once the tests pass and the changes are reviewed.
Thank you for reviewing the update! 🚀