keycloak

The flaky failure is caused by the probabilistic RANDOMIZE time-claim strategy: two independent random offsets can coincide, making iat2 - iat1 approximate the real issuance gap. Re-running usually passes, but the deterministic fix is to use ROUND with a MINUTE unit.

In tests/conformance/src/test/java/org/keycloak/tests/conformance/vci/VciConformanceRealmUtil.java, inside applyCommon(), replace the RANDOMIZE/300-second configuration with:

.attribute(OID4VCIConstants.TIME_CLAIMS_STRATEGY, TimeClaimNormalizer.Strategy.ROUND.name())
.attribute(OID4VCIConstants.TIME_ROUND_UNIT, TimeClaimNormalizer.RoundUnit.MINUTE.name())

Use MINUTE, not HOUR or DAY: credentials have a 300-second expiry, and 300 seconds is exactly five minute boundaries. Coarser units can round exp back to the rounded iat, causing credentials to be expired immediately. Rounding is an allowed unlinkability mitigation under RFC 9901 §10.1. Rebuild and rerun the Oid4VciNonHaipTestSuite conformance job.

Correct the EntityManager link in the server-development user-storage guide. Replace the lowercase path ending in /entitymanager with the case-sensitive /EntityManager.html. Verify the corrected URL returns HTTP 200, then rerun: ./mvnw install -Dtest=ExternalLinksTest -am -pl docs/documentation/tests -Pdocumentation.

Upgrade com.fasterxml.jackson.core:jackson-databind to a patched version: **2.22.3**, **2.21.7**, or **2.18.11** (affected: 2.21.5, 2.22.1, 2.22.2 and earlier lines).

**Maven:**

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.22.3</version>
</dependency>

**Gradle:**

implementation 'com.fasterxml.jackson.core:jackson-databind:2.22.3'

**Quarkus users:** the version is managed by quarkus-bom (e.g. 3.40.1 ships an affected version). Either upgrade to a newer quarkus-bom release that includes the fix, or pin the fixed jackson-databind version explicitly in your dependencyManagement section after the BOM import.

The vulnerability causes quadratic CPU consumption (N*(N+1)/2 identity comparisons) when deserializing JSON with @JsonIdentityInfo object IDs into Collection or Map types, where N forward references are resolved in reverse order — enabling denial of service with a shallow, linearly-sized payload. The patch replaces the repeated linear scan of the pending-reference accumulator with a keyed lookup structure.

**Mitigation if upgrade is impossible:** avoid deserializing untrusted/attacker-controlled JSON into identity-enabled (@JsonIdentityInfo) collections or maps, and enforce payload size limits at the API edge.

In Keycloak 26.8.0, workflow expressions support only not, and, and or. The ! character is silently dropped instead of causing a validation error, so if: "!has-role(vip)" is evaluated as if: "has-role(vip)", inverting the condition. Replace it with the supported operator: if: "not has-role(vip)". Likewise use and/or instead of &&/||. Search server logs for token recognition error at: '!' to identify affected workflows. A fix rejects unrecognized characters with workflowExpressionInvalid; upgrade to a release containing the PR "Reject workflow expressions with unrecognized characters" when available.

This behavior is intentional in Keycloak 26.6.x. When you call POST /realms/{realm}/authz/protection/resource_set with a PAT, Keycloak ignores the request-body owner and assigns ownership to the PAT subject, typically the resource server. Updating the resource with PUT does not change the owner.

To create a resource owned by another user, use the Keycloak Admin API instead:

curl -X POST \
  "http://localhost:8080/admin/realms/{realm}/clients/{client-uuid}/authz/resource-server/resource" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Alice Resource",
    "owner": "{alice-user-id}",
    "ownerManagedAccess": true
  }'

Use the client's UUID, not its clientId, and an admin token with permission to manage authorization resources. Set ownerManagedAccess according to whether the user should manage the resource. The Protection API can only create resources for the subject represented by the presented PAT; arbitrary user ownership must now be done through the Admin API.