Notifications
Clear all
Topic starter
02/08/2026 12:19 pm
TL;DR: API vulnerability volume is rising, including a jump in OAuth-related CVEs from 1 in 2012 to 42 in 2023 and a 1.5x increase in key web vulnerability detections in early 2024, according to Salt. The governance gap is that discovery and posture monitoring are outrunning the controls teams still use to manage API access and delegation.
NHIMG editorial — based on content published by Salt: LLMjacking and evolving API threat patterns
By the numbers:
- In 2020, SQL injection-related CVEs were at 466, and by 2023 that number had soared to 2,159, a 363.30% increase.
- OAuth vulnerabilities rose from just one CVE in 2012 to 42 CVEs in 2023.
- At the beginning of 2024, Salt’s internal detections in key web vulnerability categories were 1.5 times higher than those recorded in 2023.
Questions worth separating out
Q: How should security teams govern OAuth 2.0 in enterprise environments?
A: Security teams should govern OAuth 2.0 as a delegated access model with lifecycle controls.
Q: Why do AI agents create new risk for IAM and NHI programmes?
A: Because they can execute actions, inherit permissions, and connect to sensitive systems without a human acting each time.
Q: What do security teams get wrong about API security scanning?
A: They often treat API scanning as a vulnerability-only exercise.
Practitioner guidance
- Inventory OAuth-connected applications and scopes Build a current register of every third-party and internal app connected through OAuth, then record the scopes, owners, and business purpose for each one.
- Bind API findings to identity owners Route API vulnerability findings to the team that owns the affected token, integration, or workload identity, not only to the application backlog.
- Review delegated access for excessive scopes Audit tokens, refresh grants, and service credentials for scopes that are broader than the API function requires, then narrow them before the next release cycle.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- The CVE-by-CVE breakdown behind the API vulnerability trend analysis.
- Salt's internal telemetry examples for SQL injection, code injection, XSS, and path traversal.
- The OAuth detection and posture rule changes described in the source article.
- The vendor's own action items for responding to the observed API threat patterns.
👉 Read Salt’s analysis of rising API threats and OAuth exploitation patterns →
API threat patterns: what IAM and security teams need to act on?
Explore further
02/08/2026 1:20 pm
API security is now an identity governance problem as much as an application security problem. APIs frequently carry delegated access, machine tokens, and service-to-service trust, which means the control failure is often not code alone but ownership and lifecycle ambiguity. When teams cannot map which identities are allowed to call which APIs, security gaps persist even if individual flaws are patched. The practitioner conclusion is that API security must sit inside IAM and NHI governance, not beside it.
A question worth separating out:
Q: How should security teams reduce risk from exposed API secrets?
A: Start by assuming any exposed API secret will be copied, shared, and reused. The most effective response is immediate revocation, reissuance, and workload scoping, followed by short-lived credentials and replay detection. Detection without automated kill-switches only tells you that the secret was found, not that the risk has been removed.
👉 Read our full editorial: API threat patterns are rising faster than common controls can track
