CVE-2026-48558: Verified Repro With Script Download

• Affected versions: SimpleHelp 5.5.15 and earlier, and 6.0 prerelease builds before the fixed release.
• Patched versions tested: SimpleHelp 5.5.16 (SimpleHelp-linux-amd64.tar.gz, SHA256 9360af980277e1ef4330eb1ed08d981c9dfdcc4e25d87ed0552a47f5ebd5161a).
• Risk level and consequences: Critical. A remote unauthenticated attacker can authenticate as a group-authenticated technician using forged identity claims. A technician account can access the SimpleHelp technician console and, depending on group permissions and deployment, remote support / remote access capabilities.

Impact Parity

• Disclosed/claimed maximum impact: Remote authentication/authorization bypass via forged OIDC token, yielding an authenticated technician session and potential MFA bypass.
• Reproduced impact from this run: Full remote API/OIDC authentication bypass on the real SimpleHelp 5.5.15 server. The script obtains a legitimate pending OIDC state from the product API, submits a forged ID token through the genuine /oidc callback, and observes FULLY_AUTHENTICATED status for the attacker-controlled technician identity.
• Parity: full
• Not demonstrated: Post-auth remote-control actions against managed endpoints were not performed; the reproduced impact stops at a concrete authenticated technician session and technician-console page access.

Root Cause

The vulnerable SimpleHelp OIDC implementation parses JWT claims from the ID token but does not cryptographically verify the token signature before using those claims for technician authentication. Runtime/class evidence shows that SimpleHelp 5.5.15 includes utils/oauth/oidc/IDToken.class and OIDC callback classes, but no IDTokenVerifier class. The patched 5.5.16 build adds utils/oauth/oidc/IDTokenVerifier.class and related JWKS caching classes, and its callback rejects the same forged token.

The key behavioral difference is:

• 5.5.15 vulnerable: The forged token reaches OIDCAuthenticator, is parsed into an IDToken, passes group-authentication logic, registers a new anonymous/group-authenticated technician, and registers a session token.
• 5.5.16 patched: The same forged token causes the callback to fail closed; the status endpoint remains UNAUTHENTICATED.

No public fix commit hash was provided in the ticket because SimpleHelp is a commercial binary distribution; the script anchors the negative control to the vendor fixed 5.5.16 release identified in the advisory.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh.
2. The script:
   • Verifies/downloads the official SimpleHelp 5.5.15 and 5.5.16 Linux server tarballs.
   • Extracts clean vulnerable and patched server instances.
   • Initializes each real SimpleHelp server through the first-launch path.
   • Configures a real OIDC authentication provider and a non-admin Technicians technician group that allows group-authenticated/OIDC-created logins.
   • Starts a local fake OIDC IdP that returns a JWT with alg: none and a bogus signature segment.
   • Requests a real OIDC authorization URL from https://127.0.0.1/auth/v1/account/oidc_get, preserving the server-issued state.
   • Delivers the forged token through the genuine https://127.0.0.1/oidc?code=...&state=... callback.
   • Checks https://127.0.0.1/auth/v1/account/status as the post-login authorization proof.
   • Repeats the same flow against patched 5.5.16 as the negative control.
3. Expected evidence:
   • Vulnerable flow: status_after_body contains "state":"FULLY_AUTHENTICATED" and the forged identity (Forged Attacker, attacker, attacker@example.com).
   • Patched flow: callback contains Login Failed and status remains "state":"UNAUTHENTICATED".

Evidence

Primary evidence files:

• bundle/logs/reproduction_steps.log — full script stdout/stderr for the successful run.
• bundle/logs/vuln_flow.json — vulnerable HTTP/API/OIDC flow result.
• bundle/logs/patched_flow.json — patched negative-control flow result.
• bundle/logs/vuln_idp.log — fake IdP requests and the forged ID token returned to the product.
• bundle/logs/patched_idp.log — same forged-token IdP interaction for patched version.
• bundle/logs/vuln_runtime_tail.log — vulnerable server runtime log excerpts.
• bundle/logs/patched_runtime_tail.log — patched server runtime log excerpts.
• bundle/logs/class_comparison.log — class-level fix comparison showing IDTokenVerifier absent in 5.5.15 and present in 5.5.16.
• bundle/repro/runtime_manifest.json — runtime evidence manifest written by the reproduction script.

Key excerpts from the successful run:

// bundle/logs/vuln_flow.json
"status_after_body": "{\"state\":\"FULLY_AUTHENTICATED\",\"user\":{\"uniqueID\":480346,\"displayName\":\"Forged Attacker\",\"username\":\"attacker\",\"emailAddress\":\"attacker@example.com\",\"isOnline\":true},\"code\":1}"

// bundle/logs/patched_flow.json
"callback_contains_login_failed": true,
"status_after_body": "{\"state\":\"UNAUTHENTICATED\",\"code\":0}"

// bundle/logs/vuln_runtime_tail.log
[OIDCAuthenticator] Received OIDC response (...)
[ProxyServerAuthentication] Group authenticated technician via group 'Technicians'
[ServerConfig] Registering technician login for attacker / (Technicians)
[Server Config] Configuration save requested (Forged Attacker - attacker [(Technicians)] [New Anon])
[ProxyServerAuthentication] Registering session token for Forged Attacker - attacker [(Technicians)] (...)

// bundle/logs/class_comparison.log
[*] Vulnerable OIDC classes
     7852 ... utils/oauth/oidc/IDToken.class
     6340 ... com/aem/shelp/proxy/wds/OIDCCallbackManager.class
[*] Patched OIDC classes
     8796 ... utils/oauth/oidc/IDToken.class
      252 ... utils/oauth/oidc/IDTokenVerifier$1.class
     1660 ... utils/oauth/oidc/IDTokenVerifier$CachedJwks.class
    17996 ... utils/oauth/oidc/IDTokenVerifier.class

Environment details captured in logs include SimpleHelp server version/build (5.5.15 build 20260326-092709, patched 5.5.16 build 20260526-203544), bundled JRE versions, HTTPS listener startup, and the exact API/callback URLs exercised.

Recommendations / Next Steps

• Upgrade SimpleHelp servers to 5.5.16 or later, or to the fixed 6.0 release/RC identified by the vendor.
• Ensure OIDC ID tokens are validated using issuer metadata/JWKS before any claims are trusted:
  • Verify the JWT signature.
  • Reject alg: none or unsupported algorithms.
  • Validate iss, aud, exp, iat, and nonce/state binding.
• Add regression tests that submit unsigned and incorrectly signed ID tokens through the real /oidc callback and assert rejection.
• Audit existing SimpleHelp deployments for unexpected group-authenticated/anonymous technician accounts, especially identities created via OIDC.

Additional Notes

• The script was run successfully twice consecutively after the escaping/configuration fix.
• The reproduction uses the real SimpleHelp server binaries and real HTTPS API/callback paths; the only test double is the OIDC identity provider, which is attacker-controlled by design for this class of vulnerability.
• The script rewrites the IdP redirect host to 127.0.0.1 after preserving the SimpleHelp-issued callback path, code, and state, because the product derives a public hostname from its local environment. This keeps the callback on the genuine SimpleHelp /oidc endpoint while avoiding external DNS/network dependence.

Fix Coverage / Assumptions

The vendor fix appears to rely on a new invariant: every ID token consumed by the OIDC callback/authentication path must be cryptographically verified before claims are trusted for group-authenticated technician login. Because SimpleHelp is distributed as commercial binaries, no public source commit was available. Runtime and class comparison evidence shows the following binary-level changes between 5.5.15 and 5.5.16:

• utils/oauth/oidc/IDTokenVerifier.class and supporting JWKS cache classes are absent in 5.5.15 and present in 5.5.16.
• com/aem/shelp/proxy/wds/OIDCCallbackManager.class grows from 6,340 bytes to 10,556 bytes and gains OIDCCallbackManager$ActiveOIDCCallback.class and OIDCCallbackManager$OIDCTestResult.class.
• com/aem/shelp/proxy/authentication/oidc/OIDCAuthenticator.class grows from 6,188 bytes to 7,244 bytes.
• com/aem/shelp/proxy/config/authentication/AzureAuthenticationProvider.class grows from 3,860 bytes to 8,580 bytes.

The code paths explicitly covered by the tested fix include both:

1. The generic OIDC authorization-code callback used in the parent reproduction.
2. The Azure/Entra implicit/direct ID-token form-post callback tested in this variant stage.

The tested fix did not leave an observable gap for the alternate Azure/Entra path. Both the generic and Azure paths use the same /oidc callback and downstream OIDCAuthenticator / group-authentication sink, and 5.5.16 fails closed before creating a technician session.

The target's stated security scope matches this testing: the vendor advisory states that vulnerable configurations are SimpleHelp servers with an enabled OIDC Authentication Service, including OIDC-based categories labelled Active Directory, Azure, and OpenID Connect, plus a Technician Group with the OIDC service enabled and "Allow group authenticated logins" enabled. It also states that 5.5.16 and the public/fixed 6.0 release are not affected. The variant test stayed within that threat model: the input is remote unauthenticated login traffic crossing the SimpleHelp technician-authentication trust boundary, not a local/self-attacking configuration file issue.

Variant / Alternate Trigger

Tested alternate trigger: Azure/Entra-style OIDC implicit/direct ID-token callback.

• Entry point 1: GET https://127.0.0.1/auth/v1/account/login_options
• Entry point 2: GET https://127.0.0.1/auth/v1/account/oidc_get?payload=...
• Entry point 3: POST https://127.0.0.1/oidc with form fields:
  • state=<server-issued state>
  • id_token=<attacker-forged JWT with alg:none and bogus signature>
• Status proof endpoint: GET https://127.0.0.1/auth/v1/account/status

This differs materially from the parent reproduction because no fake token endpoint is contacted and no authorization code is exchanged. SimpleHelp itself generates an Azure/Entra authorization URL with response_type=id_token, response_mode=form_post, and a nonce; the variant then forges the direct callback payload that an identity provider would post back. The vulnerable server accepts the forged claims as the identity of azure-attacker@example.com / Forged Azure Attacker.

Relevant code/class anchors from the binary inspection:

• com/aem/shelp/proxy/config/authentication/AzureAuthenticationProvider.class — Azure/Entra provider; vulnerable javap evidence shows getResponseType() returns id_token and createAuthenticationMetadata() adds response_mode=form_post.

• com/aem/shelp/proxy/wds/OIDCCallbackManager.class — /oidc callback manager.

• com/aem/shelp/proxy/authentication/oidc/OIDCAuthenticator.class — OIDC callback/token-to-login authenticator.

• utils/oauth/oidc/IDToken.class — parses ID-token claims.

• utils/oauth/oidc/IDTokenVerifier.class — absent in 5.5.15 and present in 5.5.16.

• com/aem/shelp/proxy/ProxyServerAuthentication.class — downstream group-authenticated technician login sink.

• Affected version tested: SimpleHelp 5.5.15, build 20260326-092709, official Linux tarball SHA256 26cd904ebf78ac4b2c5b99f6a9659a562390777dc8fe730469e2ecfc8ad139ab.

• Fixed version tested: SimpleHelp 5.5.16, build 20260526-203544, official Linux tarball SHA256 9360af980277e1ef4330eb1ed08d981c9dfdcc4e25d87ed0552a47f5ebd5161a.

• Risk level and consequences on vulnerable builds: Critical authentication bypass. In the tested vulnerable configuration, a remote unauthenticated attacker can become a fully authenticated technician through the Azure/Entra OIDC option if OIDC group-authenticated logins are enabled and login IP restrictions permit the source address.

Impact Parity

• Disclosed/claimed maximum impact for the parent: remote authentication bypass and possible MFA bypass via forged OIDC identity token, yielding a technician session.
• Reproduced impact from this variant run: on SimpleHelp 5.5.15, the Azure/Entra direct ID-token callback produces FULLY_AUTHENTICATED status for Forged Azure Attacker / azure-attacker@example.com without a valid identity-provider signature.
• Parity: full for the vulnerable-version alternate trigger; none as a fixed-version bypass because patched 5.5.16 rejects the same forged direct-ID-token callback.
• Not demonstrated: post-auth remote-control actions against managed endpoints were not performed. The proof stops at authenticated technician-session creation and status-page authorization evidence.

Root Cause

The same underlying vulnerable sink can be reached in SimpleHelp 5.5.15 from the Azure/Entra OIDC path because the vulnerable implementation parses and trusts an ID token before verifying its signature. For Azure/Entra providers, AzureAuthenticationProvider.getResponseType() returns id_token and the provider adds response_mode=form_post; this causes /auth/v1/account/oidc_get to create an authorization URL where the identity token is returned directly to /oidc, instead of being obtained from a token endpoint after a code exchange. In 5.5.15, posting a forged JWT with alg:none, a bogus signature segment, matching aud, and the server-issued nonce/state reaches the same OIDCAuthenticator and ProxyServerAuthentication group-authentication path as the parent reproduction.

The fix commit is not public. The tested vendor fixed binary, 5.5.16, adds utils/oauth/oidc/IDTokenVerifier.class and rejects the forged Azure/Entra direct callback. This indicates the fix enforces signature/JWKS validation before the parsed IDToken is accepted by group authentication.

Reproduction Steps

1. Run bundle/vuln_variant/reproduction_steps.sh.
2. The script:
   • Verifies the official SimpleHelp 5.5.15 and 5.5.16 Linux tarball SHA256 values, reusing the downloaded repro artifacts if present.
   • Extracts clean vulnerable and patched server instances under bundle/vuln_variant/runtime-azure-implicit/.
   • Initializes each SimpleHelp server through first launch.
   • Configures an Azure/Entra-style OIDC authentication provider (type="oidc_azure") and a non-admin Technician Group with group-authenticated logins enabled.
   • Requests a real SimpleHelp OIDC authorization URL through /auth/v1/account/oidc_get.
   • Confirms the server-generated Azure authorization URL uses response_type=id_token, response_mode=form_post, state, and nonce.
   • Posts a forged unsigned/bogus-signature ID token directly to /oidc with the server-issued state.
   • Checks /auth/v1/account/status to determine whether a technician session was created.
   • Repeats the same test against patched 5.5.16.
3. Expected evidence:
   • Vulnerable 5.5.15: bundle/logs/vuln_variant/azure_vuln_flow.json contains "state":"FULLY_AUTHENTICATED" and the forged Azure identity.
   • Patched 5.5.16: bundle/logs/vuln_variant/azure_patched_flow.json contains a Login Failed callback and "state":"UNAUTHENTICATED".
   • Script exit: 1, because the alternate trigger is vulnerable-only and did not bypass fixed 5.5.16.

Evidence

Primary evidence files:

• bundle/logs/vuln_variant/reproduction_steps.log — full output from the second idempotency run of the variant script.
• bundle/logs/vuln_variant/azure_vuln_flow.json — vulnerable Azure/Entra direct-ID-token flow result.
• bundle/logs/vuln_variant/azure_patched_flow.json — patched negative-control result.
• bundle/logs/vuln_variant/azure_flow_summary.json — structured variant summary.
• bundle/logs/vuln_variant/azure_vuln_runtime_tail.log — vulnerable server runtime tail showing group-authenticated login/session registration.
• bundle/logs/vuln_variant/azure_patched_runtime_tail.log — patched server runtime tail.
• bundle/logs/vuln_variant/azure_class_comparison.log — class-level comparison showing verifier addition and Azure/OIDC class changes.
• bundle/logs/vuln_variant/fixed_version.txt — exact fixed binary identity tested.
• bundle/vuln_variant/runtime_manifest.json — runtime evidence manifest.

Key evidence excerpt from azure_flow_summary.json:

{
  "vulnerable_auth_url_direct_id_token_flow": true,
  "vulnerable_status_fully_authenticated": true,
  "patched_has_IDTokenVerifier_class": true,
  "patched_status_fully_authenticated": false,
  "patched_failed_closed": true,
  "vulnerable_status_after": "{\"state\":\"FULLY_AUTHENTICATED\",\"user\":{\"displayName\":\"Forged Azure Attacker\",\"username\":\"azure-attacker\",\"emailAddress\":\"azure-attacker@example.com\"...}}",
  "patched_status_after": "{\"state\":\"UNAUTHENTICATED\",\"code\":0}"
}

Key class-comparison excerpt from azure_class_comparison.log:

[*] Vulnerable Azure/OIDC-relevant classes
  com/aem/shelp/proxy/config/authentication/AzureAuthenticationProvider.class
  utils/oauth/oidc/IDToken.class
  com/aem/shelp/proxy/wds/OIDCCallbackManager.class
  com/aem/shelp/proxy/authentication/oidc/OIDCAuthenticator.class
[*] Patched Azure/OIDC-relevant classes
  com/aem/shelp/proxy/config/authentication/AzureAuthenticationProvider.class
  utils/oauth/oidc/IDTokenVerifier.class
  com/aem/shelp/proxy/wds/OIDCCallbackManager.class
  com/aem/shelp/proxy/authentication/oidc/OIDCAuthenticator.class

The script was executed twice. Both runs completed deterministically with exit code 1, which is the expected stage result for "alternate trigger works on vulnerable build but no fixed-version bypass was found."

Recommendations / Next Steps

• Keep the fix centralized at the ID-token acceptance boundary. Every route that constructs or receives an IDToken must call the verifier before exposing claims to OIDCAuthenticator, group filters, account lookup/linking, or technician-session creation.
• Add regression tests for both materially different OIDC modes:
  1. Generic authorization-code callback where /oidc receives code and the server obtains id_token from /token.
  2. Azure/Entra direct callback where /oidc receives a form-posted id_token directly.
• Regression tests should reject alg:none, bogus signatures, missing/empty JWKS, mismatched kid, wrong iss, wrong aud, expired exp, and nonce/state mismatches.
• Ensure Azure/Entra-specific validation uses the correct issuer/JWKS metadata for the configured tenant and does not silently fall back to claim-only parsing if metadata retrieval fails.
• Continue documenting operational mitigations from the vendor advisory: disable OIDC group-authenticated logins if patching is delayed, enforce technician login IP restrictions, and audit newly created OIDC/anonymous technician accounts.

Additional Notes

• Idempotency confirmed: bundle/vuln_variant/reproduction_steps.sh was run twice consecutively and completed both times with the expected exit code 1.
• The variant uses the real SimpleHelp server binaries and real HTTPS /auth/v1/account/oidc_get, /oidc, and /auth/v1/account/status endpoints. No source checkout was modified.
• The only synthetic input is the forged ID token, which models the attacker-controlled OIDC response at the trust boundary described by the vendor advisory.
• No fixed-version bypass was found in the tested 5.5.16 Linux server build.