Resource Injection

Catch-all bucket:

• URI scheme injection via desktop client URL handlers (Nextcloud Desktop CVE-2021-22879)
• object-injection-to-SQLi (Stripe-billing-typographic)
• cloud-resource tag-based replacement (AWS Load Balancer Controller)
• Ruby rdoc symlink-attack file injection
• Jupyter notebook HTML injection performing arbitrary POST as victim
• Jira issue title HTML/CSS injection with browser-quirk gadget chain (GitLab CVE-2022-1940)
• GitHub Actions ContainerStepHost env-var smuggling. Mostly product-specific; CVE-marker-driven.

• Nextcloud / Acronis / similar desktop sync clients
• AWS Load Balancer Controller / Kubernetes operators
• Ruby rdoc / wait_writable file utilities
• Jupyter / Jira / GitLab issue trackers
• GitHub Actions runners

• Submit malicious URI scheme to desktop client
• Submit object body that the deserializer turns into SQL fragment
• Tag a cloud resource with the same tag that the controller searches for
• Plant a symlink in user-controlled directory
• Inject HTML/CSS into Jupyter / Jira / comment fields
• Smuggle newline + env-var into GitHub Actions secret

• scp://attacker/file (Nextcloud Desktop)
• {"email":{"email":1},"password":"1234"} (object injection)
• Tag: elbv2.k8s.aws/cluster=victim
• ln -s /etc/passwd /attacker-controlled-dir/symlink
• <form action="https://gitlab/admin/users"><input name=...>

Mostly out of scope for direct probing. Compose with Nuclei for the listed CVEs.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

Most of this category requires source/binary inspection.

Manual Testing Methodology

Here is a systematic approach to identifying Resource Injection vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Resource Injection specifically, substitute every resource-identifying parameter (a filename, connection name, queue identifier, service reference) with values pointing at unexpected internal resources, alongside path-traversal- and SSRF-style variants where the identifier resembles a path or URL.

Compare the response against your baseline, looking specifically for evidence that the application actually reached or acted on an unintended resource — different data returned, a different backend touched, or an error revealing an internal resource name that shouldn't have been reachable from that input.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Resource Injection, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Resource injection lets attacker-controlled input determine which specific resource, a file, a database connection, a queue, an external service, an application interacts with, when that choice should have been fixed or constrained by the application itself. It's a broader pattern than path traversal or SSRF specifically: the common thread is a resource identifier (not necessarily a URL or a file path) being taken from user input and used to select what the backend touches next.

The consequences depend entirely on what kind of resource gets substituted — reaching an unintended database, queue, or cache instance can expose or corrupt data that belongs to a different tenant or context, while reaching an unintended external service can enable the same SSRF-style internal reconnaissance even when the vector isn't a conventional URL parameter.

Because the specific resource type varies so much by application, this class is easy to underestimate in a generic review — the fix is conceptually simple (never let user input select a resource without going through an allowlist) but the places it can hide are numerous.

Prevention and Secure Coding

Preventing Resource Injection takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Map user input to an internal identifier, never a live resource reference directly. Have user-supplied values select from a server-side allowlist or lookup table rather than being used directly as a connection string, file handle, queue name, or service reference.

Apply the same discipline used for SSRF and path traversal. If the resource identifier happens to be a URL or file path, the allowlist and containment controls for those specific classes apply directly.

Scope credentials to the specific resource a component should reach. Least-privilege access limits the blast radius even if a resource-selection check is bypassed.

Log and alert on out-of-allowlist resource requests. An attempt to reach a resource outside the expected set is a strong signal worth alerting on, not just silently rejecting.