Callback poisoning is an attack where an adversary manipulates a system’s callback mechanism so it sends data or control requests to an attacker-controlled destination. It commonly targets webhooks, OAuth redirect handling, and other outbound callbacks, letting the attacker steal tokens, redirect flows, or influence trust decisions.
How callback poisoning works
Callback poisoning abuses a system feature that is supposed to call back to a trusted endpoint after an event, such as a webhook trigger or OAuth redirect. The attacker changes the destination, parameters, or trust context so the callback reaches an attacker-controlled target instead of the intended recipient.
This is dangerous because callback flows often carry tokens, signed assertions, authorization codes, or other sensitive state. If the receiving system trusts the callback too much, the attacker can capture secrets, alter control flow, or make the victim service act on untrusted input.
Where callback poisoning shows up
It most often appears in integrations that exchange data or control across trust boundaries. Common examples include webhook targets, redirect URI handling, payment or notification callbacks, and any workflow that sends data outward and then relies on the response path for a security decision.
Callback poisoning is especially effective when the application accepts user-influenced destinations, matches callbacks loosely, or treats callback-originated data as automatically authenticated. The weakness is not the callback itself, but the assumption that the return path is inherently trustworthy.
Why callback poisoning is security-relevant
The attack can expose credentials, session material, or one-time authorization values, then use those values to pivot into account takeover or unauthorized API access. It can also corrupt downstream business logic when a forged callback triggers state changes that the system believes came from a legitimate partner or identity provider.
Because callback flows are often embedded in normal application behavior, the abuse can look like routine integration traffic. That makes it a useful technique for attackers who want to stay inside expected protocol patterns rather than exploit an obvious software crash.
How defenders reduce callback poisoning risk
Defence starts with strict destination validation, exact allowlisting, and callback binding to the original request context. The callback should be constrained to a known endpoint, with cryptographic verification or equivalent proof that the response belongs to the expected transaction.
Teams should also review outbound integrations for open redirect-like behaviour, host header dependence, weak URL parsing, and any place where user-controlled input can influence where a callback is sent. Where the design cannot be changed immediately, limit the sensitivity of data sent in the callback and reduce the trust granted to the return flow.
Operationally, monitor for unusual callback destinations, unexpected parameter changes, and failed verification events. If a callback path is abused, rotate any exposed tokens or secrets and review whether the attacker could have replayed or modified the surrounding transaction state.
Risk and Threat Considerations
Callback poisoning creates a high-value abuse path because it turns an expected trust relationship into an exfiltration or redirection channel. The same weakness can leak secrets, redirect authentication flows, or make a workflow accept attacker-supplied state as legitimate.
Failure mechanism: The application accepts or computes a callback destination without strong binding to the original transaction, so the attacker substitutes an endpoint they control and intercepts the callback payload or flow outcome.
Impact: Successful exploitation can expose tokens, session material, authorization codes, or other sensitive data, and may also enable unauthorized actions, account compromise, or fraudulent trust decisions in connected systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Callback flows can expose privileged functions through trusted return paths. |
| API2 — Broken Authentication | Poisoned callbacks can steal or replay auth values used to prove a session or transaction. | |
| Recommendation — Enforce function-level checks on callback-triggered actions and reject unauthorized state changes. Verify callback-originated assertions and invalidate any exposed credentials or tokens. | ||
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | Callback poisoning often abuses the trust placed in transaction and session return paths. |
| Recommendation — Bind callback handling to the expected session or transaction and verify authenticity before processing. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OAuth redirect handling is a common callback-poisoning target because redirect trust is security-critical. |
| Recommendation — Validate redirect and callback handling rigorously to prevent authorization code and token abuse. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Callback handling is an application security concern that requires secure design and validation. |
| Recommendation — Review callback logic for destination validation, input handling, and trust-boundary failures. | ||
Practitioner Guidance
What to watch for: Treat any callback design that relies on loosely matched URLs, dynamic redirect targets, or partner-supplied endpoints as a security review item. The safest pattern is a tightly bounded callback scheme with explicit destination validation and clear transaction binding.
Practitioner takeaway: If the callback destination can be influenced, the trust boundary can usually be influenced too.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org