CVE-2026-48558

What it actually does

SimpleHelp 5.5.15 and earlier, and affected 6.0 pre-release builds, fail to cryptographically verify the signature on OIDC ID tokens during login when OIDC authentication is enabled. A remote unauthenticated attacker can craft an ID token with arbitrary identity claims and have it accepted as valid, resulting in an authenticated technician session. Because technician access is highly privileged in remote support software, successful exploitation can lead to control of managed systems, data access, configuration changes, and potentially full compromise of downstream endpoints. In configurations where MFA is enforced through the identity provider, the forged-token path may also bypass MFA because the application trusts the unverified token rather than a validated identity-provider assertion.

Why it matters to the business

This is a critical authentication bypass in a remote administration product. If exposed and configured for OIDC, an attacker may gain technician-level access without credentials, potentially enabling remote access to customer or employee systems, operational disruption, data theft, malware deployment, and lateral movement. The vulnerability is listed in CISA KEV with a remediation due date of 2026-07-02 and is reported as actively exploited in the wild, so organizations should treat internet-exposed SimpleHelp deployments as high-priority emergency remediation targets. Although KEV does not currently mark it as ransomware-associated, compromise of a remote support platform is a common precursor to broad enterprise intrusion.

How an attack unfolds

An attacker first identifies a SimpleHelp server that has OIDC login enabled and is running a vulnerable version. Instead of authenticating through the legitimate identity provider, the attacker submits a forged OIDC ID token to the SimpleHelp login flow. Because the vulnerable server accepts the token without validating its cryptographic signature, the attacker can choose identity claims that map to a technician account or privileged technician role. The server then creates a fully authenticated technician session for the attacker. From there, the attacker can use legitimate SimpleHelp functionality to access managed devices, run remote support actions, modify settings, collect sensitive information, or deploy additional tooling. Reported in-the-wild exploitation and association with Djinn Stealer activity increase the importance of reviewing for post-authentication actions after any suspicious OIDC login.

How to fix it

Upgrade SimpleHelp to a vendor-fixed, non-vulnerable release immediately. The supplied data does not provide exact fixed version numbers, so verify the corrected version directly from SimpleHelp security advisories and release notes; at minimum, do not continue running version 5.5.15 or earlier or affected 6.0 pre-release builds with OIDC enabled. If an immediate upgrade is not possible, disable OIDC authentication until patched, restrict SimpleHelp access to trusted networks or VPN, block public internet access to the service, and enforce strong network-level access controls. Rotate SimpleHelp technician credentials, review and revalidate technician accounts, invalidate active sessions, and review identity-provider/OIDC configuration after patching. Because exploitation grants legitimate-looking technician access, remediation should include endpoint and remote-session review, not only application patching.

How to confirm the fix worked

Confirm the installed SimpleHelp version is newer than the vulnerable range and matches the vendor-fixed release. Verify that no affected 6.0 pre-release build remains in use. If OIDC remains enabled, confirm the patched application rejects unsigned, tampered, or incorrectly signed ID tokens and only accepts tokens from the configured issuer with the expected audience, expiration, and signature validation. Check that public exposure is removed or limited to approved access paths. Review current active sessions and technician accounts after remediation, and confirm session invalidation or service restart occurred where required by the vendor. For vulnerability management validation, scan externally and internally for exposed SimpleHelp services and reconcile results against asset inventory and patch records.

Typical attack path

1. Discover an exposed SimpleHelp instance and determine whether OIDC authentication is enabled.
2. Confirm the instance is running SimpleHelp 5.5.15 or earlier, or an affected 6.0 pre-release build.
3. Create a forged OIDC ID token containing attacker-controlled identity and authorization claims.
4. Submit the forged token to the SimpleHelp OIDC login flow without completing legitimate identity-provider authentication.
5. Obtain an authenticated technician session because the server does not verify the token signature.
6. Use technician privileges to access managed endpoints, alter configuration, collect data, or stage malware or stealer payloads.
7. Persist through newly created accounts, changed settings, remote access tooling, or compromised downstream endpoints.

How to detect it

To determine whether exploitation already occurred, correlate SimpleHelp authentication logs, OIDC/identity-provider logs, reverse-proxy or web access logs, and endpoint telemetry from systems accessed through SimpleHelp. Look for successful SimpleHelp technician logins that have no corresponding successful identity-provider authentication event, especially logins using OIDC, unusual source IP addresses, impossible travel, new user-agent strings, or activity outside normal support hours. Search web and application logs for JWTs or token headers indicating unsigned tokens, such as alg=none, or tokens with issuer, audience, subject, email, group, or role claims that do not match the configured identity provider. Review SimpleHelp audit logs for newly created technician accounts, privilege changes, configuration changes, remote sessions, file transfers, command execution, downloads, or endpoint access shortly after suspicious OIDC logins. On managed endpoints, examine EDR, process creation, PowerShell, shell, file-write, persistence, and network logs for activity initiated through SimpleHelp sessions, especially credential theft, stealer behavior, or unexpected remote administration tools. Because Djinn Stealer has been reported in the exploitation context, prioritize hunts for stealer-like behavior such as browser credential database access, credential archive creation, outbound connections to unknown infrastructure, and suspicious file staging after SimpleHelp remote sessions.

• alg":"none
• alg=none
• eyJhbGciOiJub25lIn0
• eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
• successful OIDC login with no matching identity provider authentication event
• SimpleHelp technician login from unusual source IP
• new technician account created
• technician privilege changed
• SimpleHelp remote session started outside normal hours
• OIDC token signature validation failed
• unsigned JWT
• Djinn Stealer

What your security team should do

• Treat exposed SimpleHelp servers using OIDC as emergency-risk assets because the flaw is KEV-listed, CVSS 10.0, and reported as actively exploited in the wild.
• Patch to a vendor-fixed SimpleHelp release immediately, prioritizing internet-facing systems and any system integrated with OIDC.
• If patching cannot be completed immediately, disable OIDC and restrict SimpleHelp access to trusted networks or VPN-only paths.
• Invalidate active SimpleHelp sessions and rotate technician credentials after remediation.
• Review SimpleHelp technician accounts, permissions, configuration changes, and remote support session history for unauthorized activity since at least the publication date, 2026-06-12.
• Hunt for suspicious OIDC login attempts, unsigned JWTs, invalid issuer/audience patterns, logins not reflected in identity-provider authentication logs, and post-login technician actions from unusual IP addresses.
• Investigate any signs of stealer deployment or credential collection activity, including activity associated with reported Djinn Stealer exploitation context.
• Monitor for new administrator or technician accounts, configuration changes, unusual remote-control sessions, file transfers, command execution, or endpoint access shortly after OIDC logins.
• Ensure remediation aligns with the CISA KEV due date of 2026-07-02 or sooner for regulated environments.
• Add compensating controls such as WAF/reverse-proxy restrictions, IP allowlisting, centralized logging, and alerting on anomalous SimpleHelp authentication and technician activity.