PasswordHasher errors on Adobe 2025: JPMS blocks reflection into PBKDF2KeyImpl

[bpamiri]

Symptom

PasswordHasherSpec: 17 of 24 specs error on Adobe 2025 only (every database leg, matrix run 28815315339):

java.lang.reflect.InaccessibleObjectException: Unable to make public byte[]
com.sun.crypto.provider.PBKDF2KeyImpl.getSalt() accessible: module java.base
does not "opens com.sun.crypto.provider" to unnamed module

Introduced with #3288 (2026-07-06) — this is the only new cross-engine failure from the #2962 feature merges (verified by diffing failing-bundle sets against the 2026-06-28 matrix baseline: Lucee 6/7, Adobe 2023, and BoxLang show no new failures).

Root cause

vendor/wheels/auth/PasswordHasher.cfc ($deriveKey) chains generateSecret(keySpec).getEncoded(). The returned key is a com.sun.crypto.provider.PBKDF2KeyImpl — a JDK-internal class java.base does not open. Adobe 2025's reflection layer makes the concrete class's public methods accessible en masse when dispatching the member call, and its newer JVM rejects that with InaccessibleObjectException (the message names getSalt() because that's the first method the bulk setAccessible trips on). Adobe 2023, Lucee, and BoxLang tolerate the same call — 24/24 there.

Fix

Invoke getEncoded() through the exported javax.crypto.SecretKey interface Method object instead of the concrete class — public interface methods require no opens. PR follows.

Lesson (CLAUDE.md candidate)

Calling members on JDK-internal implementation classes returned by factory APIs (SecretKeyFactory.generateSecret(), Cipher, KeyAgreement results, …) is an Adobe 2025 crash class. Route member calls through the exported interface when the runtime class lives in an unexported com.sun.*/jdk.internal.* package.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes a reproducible crash — java.lang.reflect.InaccessibleObjectException on Adobe 2025 only (every DB leg, matrix run 28815315339), with 17/24 PasswordHasherSpec specs erroring — plus a precise root cause and a concrete fix. That is a clear "what happened / what I expected" defect, not a design question.

Suspected layer

security (auth) — see .ai/wheels/security/ and, primarily, .ai/wheels/cross-engine-compatibility.md. The defect lives in vendor/wheels/auth/PasswordHasher.cfc::$deriveKey.

Fix sketch

$deriveKey chains generateSecret(keySpec).getEncoded(), invoking getEncoded() on a JDK-internal com.sun.crypto.provider.PBKDF2KeyImpl instance. Adobe 2025 reflection bulk-setAccessibles the concrete class public methods and its newer JVM rejects that (java.base does not opens com.sun.crypto.provider). Fix: route the getEncoded() call through the exported javax.crypto.SecretKey interface Method object so the reflected member lives in an exported package requiring no opens. Single-file change in vendor/wheels/auth/PasswordHasher.cfc; verify against Adobe 2025 (24/24) and confirm no regression on Lucee 6/7, Adobe 2023, BoxLang.

Confidence: medium

The fix shape is clear and mechanical, but two auto-downgrade rules fire: the change touches an auth flow, and it is an engine-specific cross-engine concern (Adobe 2025 JPMS vs. Lucee/Adobe 2023/BoxLang) — both cap confidence at medium.

[wheels-bot]

Wheels Bot — Fix on hold for human review

The proposed fix touches a sensitive area (vendor/wheels/auth/PasswordHasher.cfc — password-hashing code, and an Adobe 2025-specific cross-engine reflection concern) and the bot's safety net requires a human in the loop before any code is written.