bump @adobe/aio-lib-state to 5.3.1

[thedoc31]

Description

Bumps @adobe/aio-lib-state from ^3 to ^5.3.1. The v3 release line carried @azure/cosmos as a
direct dependency, which pulled in the vulnerable [email protected]. The v5 release line removed @azure/cosmos
entirely, breaking the vulnerability chain.

The public API shape used by this library (init(), state.get(), state.put() with no TTL) is unchanged
between v3 and v5 — both return { value, expiration } from get(). However, the backend changed from
CosmosDB in v3 to an HTTP-based Adobe I/O service in v5, meaning real validation requires a functional
environment, not unit tests.

Related Issue

MWPW-195032 — CVE-2026-41907 / SNYK-JS-UUID-16133035:
High severity — Improper Validation of Specified Index, Position, or Offset in Input in uuid

Motivation and Context

[email protected] (CVE-2026-41907) is introduced transitively via:

@adobe/aio-lib-events → @adobe/aio-lib-state@^3 → @azure/[email protected] → [email protected]

@adobe/aio-lib-state v5 removed @azure/cosmos entirely. Upgrading eliminates the vulnerable package
from the dependency tree.

How Has This Been Tested?

Unit tests pass, but are not sufficient to validate this change. @adobe/aio-lib-state is fully mocked in the unit
test suite — the mock does not move when the library moves, so unit tests will pass regardless of whether
the v5 library works correctly at runtime.

Real validation requires running the e2e suite (npm run e2e) against a live Adobe I/O environment with
valid credentials. This has not been run as part of this PR.

Screenshots (if appropriate):

N/A

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[pru55e11]

Tested this PR end-to-end against the Adobe State Service v5 in Adobe I/O Runtime. tl;dr — it works, and the production dep tree is CVE-clean.

Why aio-lib-events depends on aio-lib-state

Only one code path uses it: src/signatureUtils.js. Adobe I/O Events signs webhook payloads with rotating private keys; the corresponding public PEMs are served from static.adobeioevents.com/prod/keys/pub-key-<uuid>.pem. To avoid hitting CloudFront on every event for high-volume consumers, fetchPubKeyFromCacheOrApi caches the fetched PEMs in aio-lib-state keyed by the PEM filename, with the default 24h TTL. The cache survives across action invocations and containers within the same namespace.

So the dependency is legitimate — it's a public-key cache for verifyDigitalSignatureForEvent.

Tests run

Set up a dedicated Console workspace, scaffolded an App Builder app, npm pack'd this PR branch, and installed it. npm ls confirms @adobe/[email protected] → @adobe/[email protected] deduped.

A. Direct cache-path exercise — Runtime action calling fetchPubKeyFromCacheOrApi plus direct state.put/state.get round-trips against a real CloudFront PEM URL:

step	result
stateLib.init() (v5)	12–41 ms
direct state.put(PEM) / state.get	round-trip OK, returned { value, expiration } with the expected 24h TTL
1st fetchPubKeyFromCacheOrApi (miss → fetch → put)	256 ms
2nd fetchPubKeyFromCacheOrApi (hit)	19 ms — 13.5× speedup
cache surviving across container invocations	yes (same expiration timestamp observed from a fresh container)

B. Full E2E with a real Adobe-signed event — created a custom event provider + event metadata + webhook registration pointing at a Runtime action; the registration challenge handshake succeeded (status=verified), then published CloudEvents and watched Adobe sign + deliver them. The action called eventsClient.verifyDigitalSignatureForEvent(rawBody, recipientClientId, { digiSignature1, digiSignature2, publicKeyPath1, publicKeyPath2 }):

event	cacheBefore	cacheAfter	verifyMs	totalMs	verified
1st delivery	MISS, 0 B	POPULATED, 451 B	135	365	true
2nd delivery	HIT, 451 B	HIT, 451 B	80	140	true

The 2nd delivery proves the v5 cache path is doing real work — state.get returns the 451-byte PEM the 1st delivery stored, no CloudFront round-trip happens, and the signature still verifies against the cached key. ~2.6× faster end-to-end.

Other observations

• npm audit --omit=dev on this PR's tree → 0 vulnerabilities. The 7 vulns npm audit still reports come from codecov and jest-junit devDeps ([email protected] reachable through teeny-request), not anything a consumer of aio-lib-events would pull in.
• Behavioral compatibility is fully preserved: v5 init() works without arguments in Runtime (picks up OW_NAMESPACE/OW_AUTH from env), state.get returns the same { value, expiration } shape, default TTL behavior matches what the comment in signatureUtils.js advertises.
• Performance is good — state.get round-trips are well under 100 ms in us-east runtime.

LGTM.