# Unvalidated identity trusted as authentication

Caller-supplied name, CN, or integrity data used as identity without verifying a certificate or trusted source

_Area: Network devices and IoT. Seen in 4 disclosed reports; latest 2026-10-12. Updated 2026-11-01._

## How it works
A service needs to know who is calling. Instead of proving identity cryptographically, it reads an identifier the caller supplies — a certificate DN string, a client cert thumbprint, an advertised service name, or a hash from a configurable server — and treats it as proof. The assumption that breaks: that the caller cannot choose these values, or that a value only arrives after verification. When the value is attacker-chosen, the check passes for anyone.

## Where it shows up
- Login/authenticate methods taking a CN= or DN string parameter directly, with no certificate object in scope [E1](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-weaponizing-check-point-management-cve-2026-93616.md)
- TLS configured to *request* client certs rather than *require* them, leaving an app-layer check as the only gate [E2](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-detecting-solarwinds-arm-cve-2026-28326.md)
- Fallback auth paths keyed by a shared secret shipped in every installer, with no locality check, on a listener bound to all interfaces [E2](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-detecting-solarwinds-arm-cve-2026-28326.md)
- Privileged services exposing config/repoint methods (reference server, port, mode) without authentication [E3](https://bugbountylibrary.com/r/blog%3Ablog-quarkslab-com-myreport-updater-from-grpc-to-system-html.md)
- Integrity checks (MD5, size, expected hash) fetched from the same configurable source as the download [E3](https://bugbountylibrary.com/r/blog%3Ablog-quarkslab-com-myreport-updater-from-grpc-to-system-html.md)
- Discovery code that keeps both an advertised name and a resolved IP, then uses the name for URI or credential lookup [E4](https://bugbountylibrary.com/r/ghsa%3AGHSA-vx5f-957p-qpvm.md)

## How to review
Find every place identity or integrity is *asserted* and ask what proves it. The invariant: an identity value must be derived from a verified credential (a validated certificate chain, a locally-held secret, a resolved address), never from a caller-supplied string or a remote-configurable source. Concretely: does the auth function receive a certificate, or just a name? Is the TLS client-cert mode require or request? Does the integrity hash come from a different trust domain than the payload? For discovery, does every consumer of the advertised identifier use the resolved IP instead?

## How finders spotted it
- Diffed patched vs unpatched builds; a jar citing a single change ticket (most cite many) pointed at the vulnerable parameter, and diffing all replacement jars found login and write fixes in shared jars [E1](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-weaponizing-check-point-management-cve-2026-93616.md)
- Decompiled and diffed two versions, traced the fallback auth branch and the shipped secret, and noted a gRPC status-code change enabling patch-state detection [E2](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-detecting-solarwinds-arm-cve-2026-28326.md)
- On an assumed-breach assessment, looked for user-level processes talking to a privileged service, then tested whether the reference server and integrity values could be attacker-controlled [E3](https://bugbountylibrary.com/r/blog%3Ablog-quarkslab-com-myreport-updater-from-grpc-to-system-html.md)
- Code review noticed add_server keeps both name and ip, but get_uri() and password lookup use name while only the RPC client uses ip — an inconsistent trust boundary [E4](https://bugbountylibrary.com/r/ghsa%3AGHSA-vx5f-957p-qpvm.md)

## Variants seen
- Forged SIC identity via caller-supplied CN= string minting a session [E1](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-weaponizing-check-point-management-cve-2026-93616.md)
- Hardcoded HMAC key in a fallback auth path on an all-interfaces listener [E2](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-detecting-solarwinds-arm-cve-2026-28326.md)
- Unauthenticated privileged config method plus circular integrity check [E3](https://bugbountylibrary.com/r/blog%3Ablog-quarkslab-com-myreport-updater-from-grpc-to-system-html.md)
- Zeroconf-advertised name used for URI and credential lookup, falling back to a global default password [E4](https://bugbountylibrary.com/r/ghsa%3AGHSA-vx5f-957p-qpvm.md)

## Impact and severity
All four reach high impact. E1 chains forged session, path traversal, and cron write to root RCE. E2 reaches SYSTEM RCE and borrows a registered client's identity for downstream AD/file/Exchange rights. E3 yields SYSTEM file write and DLL hijack RCE. E4 leaks reusable auth hashes replayable against other servers sharing the password. Impact rises with chaining and with how far the borrowed identity's downstream rights reach [E1](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-weaponizing-check-point-management-cve-2026-93616.md)[E2](https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-detecting-solarwinds-arm-cve-2026-28326.md)[E3](https://bugbountylibrary.com/r/blog%3Ablog-quarkslab-com-myreport-updater-from-grpc-to-system-html.md)[E4](https://bugbountylibrary.com/r/ghsa%3AGHSA-vx5f-957p-qpvm.md).

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-weaponizing-check-point-management-cve-2026-93616.md
- E2: https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-detecting-solarwinds-arm-cve-2026-28326.md
- E3: https://bugbountylibrary.com/r/blog%3Ablog-quarkslab-com-myreport-updater-from-grpc-to-system-html.md
- E4: https://bugbountylibrary.com/r/ghsa%3AGHSA-vx5f-957p-qpvm.md