OpenTelemetry's Azure auth extension doesn't actually check your tokens
A CVSS 8.1 bypass in azureauthextension lets any valid Azure token past your OTel collector. Also: two SOGo SQL injection bugs (PostgreSQL, MariaDB), a busted IPv6 allow-list in Auth Proxy, and a Zoom Rooms installer DLL hijack on Windows.
Nothing's on fire, but one of these deserves your attention fast. The OpenTelemetry Collector's Azure auth extension doesn't actually validate incoming JWTs, so anyone with any valid Azure token can waltz past your collector's authentication. CVSS 8.1, not yet exploited in the wild. Behind that, two SOGo SQL injection bugs and a couple of lower-priority fixes round out the day.
Today's CVEs
Sorted by urgencyCVE-2026-42602
NVDAn attacker who holds any valid Azure access token (for ARM, Graph, Key Vault, Storage, whatever) can authenticate to your OpenTelemetry collector's receivers if they're protected by the azureauthextension. The extension never actually validates the incoming JWT. It just mints its own token using a scope pulled from the client's Host header, then does a simple string comparison. Pick the right Host value, send a token you already have, and you're in. Tokens stay valid for hours.
- Included because
- authentication bypass; network-accessible; low attack complexity; CVSS 8.1
- Affected estate
- OpenTelemetry Collector deployments using auth: azure_auth with azureauthextension versions 0.124.0 to 0.150.0.
- How to check
- Check your collector config for 'auth: azure_auth' in any receiver block, then confirm the extension version in your dependency manifest or container image tag.
- Action
- Upgrade azureauthextension to version 0.151.0 or later.
- Urgency
- Patch within 24 hours
- Why it matters
- Any Azure token holder can bypass authentication on your collector receivers, giving them access to push or query telemetry data.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-46446
NVDSOGo before 5.12.7 has a SQL injection bug in its password-change flow when you're using PostgreSQL or MariaDB with cleartext password storage. An attacker who can hit the password change endpoint can inject SQL through the c_password parameter. This only applies if your SOGo instance stores passwords in cleartext, which narrows the blast radius but makes it worse if you're in that camp.
- Included because
- SQL injection; authenticated but low complexity; common groupware product; CVSS 7.1
- Affected estate
- SOGo installations before version 5.12.7 using PostgreSQL or MariaDB with cleartext password storage.
- How to check
- Run 'sogo-tool --version' or check your package manager. Review your SOGo config for the password storage method and database backend.
- Action
- Upgrade SOGo to 5.12.7 or later.
- Urgency
- Patch this week
- Why it matters
- SQL injection in the password-change flow can let an attacker read or modify your database.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-46445
NVDA separate SQL injection bug exists in SOGo before 5.12.7 when PostgreSQL is the backend. Unlike CVE-2026-46446, this one isn't limited to the cleartext-password scenario. If you're running SOGo with PostgreSQL, you're exposed.
- Included because
- SQL injection; common groupware product; PostgreSQL backend; CVSS 7.1
- Affected estate
- SOGo installations before version 5.12.7 using PostgreSQL.
- How to check
- Run 'sogo-tool --version' or check your package manager. Confirm PostgreSQL is the configured database backend.
- Action
- Upgrade SOGo to 5.12.7 or later.
- Urgency
- Patch this week
- Why it matters
- SQL injection with a PostgreSQL backend can expose or corrupt your mail and calendar data.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-33376
NVDIf you use IPv6 addresses in your Auth Proxy allow-list without specifying a subnet mask, the system defaults to /32 instead of /128. That means your allow-list is effectively meaningless for IPv6, since /32 covers an enormous range and lets unauthorized sources through. Only the Auth Proxy feature is affected. Okta, SAML, LDAP, and other auth methods are fine.
- Included because
- authentication bypass potential; misconfiguration default; CVSS 7.4
- Affected estate
- Deployments using the Auth Proxy feature with IPv6 allow-list entries that lack explicit subnet masks.
- How to check
- Review your Auth Proxy configuration for IPv6 addresses without a /128 (or other explicit) mask.
- Action
- Append /128 to each IPv6 address in the Auth Proxy allow-list, then apply the vendor's fix.
- Urgency
- Patch this week
- Why it matters
- The overly broad /32 default lets unauthorized IPv6 sources bypass your Auth Proxy allow-list.
- Source
- NVD
Evidence trail
- NVD: View source
CVE-2026-30906
NVDThe Zoom Rooms installer for Windows before version 7.0.0 searches for libraries in untrusted directories. A local attacker who can place a malicious DLL in the right path can escalate privileges when the installer runs. This requires local access and an authenticated user to trigger the install, so remote exploitation isn't a factor.
- Included because
- privilege escalation; requires local access; common enterprise product; CVSS 7.8
- Affected estate
- Windows endpoints with Zoom Rooms installed at versions before 7.0.0.
- How to check
- Check the installed Zoom Rooms version in Programs and Features or via your software inventory tool.
- Action
- Update Zoom Rooms to version 7.0.0 or later.
- Urgency
- Monitor and patch
- Why it matters
- A local user could escalate to higher privileges on shared conference room or kiosk systems during install or upgrade.
- Source
- NVD
Evidence trail
- NVD: View source
One email, every weekday morning.
You're in. Check your inbox.
From the field notes
From this beat
Read the rest of the field notes →