When the File Is the Attack: Detecting Arbitrary File Access with Oligo ADR

TL;DR

Oligo ADR now detects arbitrary file access exploits: path traversal, XXE, Zip Slip, and SSRF used to read local files. New behavioral rules also catch what attackers do once they can touch the filesystem. 

These attacks matter because they don't need to run anything to succeed. If an attacker tricks your application into reading /etc/shadow, a Kubernetes service account token, or a cloud credentials file, the attack has already worked. No reverse shell, no unexpected binary, no child process spawned by a web server. The application just opened a file, which it does thousands of times a day.

That's why runtime tools built to catch unexpected execution miss these attacks, and why tools watching traffic or the OS can't tell an abused file read from a normal one. Oligo can, because it traces every file the application opens back to the exact function that opened it. It catches the technique however the payload is disguised, and every alert points to the code that needs fixing.

‍What Oligo detects

Until now, ADR detections centered on attacks that run code: an exploit that drives a library to spawn a shell or execute a command it was never meant to. With this release, ADR also covers attacks that only need to touch a file. The new rules come in two families.

Exploitation rules catch the technique while it's happening: path traversal, SSRF and XXE used to read local files, and Zip Slip archives that write outside their target folder. These cover Java, Python, and Node.js.

Suspicious file activity rules catch what an attacker does next: planting a hidden backdoor, tampering with the application's dependencies, or snooping through sensitive system files. CWP tools see a process touching a file. These rules see which part of the application touched it and whether that behavior is normal for that code, so routine activity stays quiet and real threats stand out. Because they key on behavior rather than a language-specific technique, they work for applications in any language, including Ruby and Go.

It's often the whole attack

Arbitrary file access covers any case where an attacker gets an application to read or write a file it was never meant to touch. Reads expose secrets: passwords, keys, tokens, configuration. Writes plant things: a backdoor, a tampered dependency, a file dropped outside the folder it was supposed to land in.

One file read can be the difference between a bug in a single service and a full breach. A stolen service account token can open the whole cluster. A cloud credentials file can open the account behind it, along with the databases, storage, and backups it controls.

After code execution, it's the most damaging thing an attacker can do to a running application. Path traversal, the best-known technique, ranks #6 on MITRE's 2025 CWE Top 25 of the most dangerous software weaknesses, and it's common enough in real-world attacks that CISA and the FBI issued a Secure by Design alert dedicated to it.

Where other tools go blind

Most teams already have tools pointed at this problem. The trouble is where those tools are standing. Each one watches a single layer, so each one sees only its own slice of the attack.

• WAF and API security tools watch incoming traffic. They can flag a request that looks like an exploit, but re-encoding a path or reshaping a payload is often enough to get past them. When they do flag something, they can't confirm it ever reached a file, which makes for a lot of false alarms.
• CWP, CDR, and EDR tools watch the operating system. They can see that a file was opened, but not which part of the application opened it or why. The authentication module reading a credentials file and an upload handler reading that same file through path traversal look identical to the OS.
• SAST and DAST find weak spots before the application ships, but see nothing once it's live and under attack.
• RASP runs inside the application, but usually requires code changes or extra tooling, and typically relies on fixed patterns of known exploits.

What none of them assembles, while the app is running, is the whole chain: the request that came in, the function that ran, and the file it touched. Arbitrary file access lives in the gap between the traffic layer and the OS layer.

How Oligo closes the gap

Oligo ADR works from inside the running application. Its eBPF-based sensor sees which libraries and functions actually execute, and traces every file the application opens back to the exact function that opened it. That changes what an attacker has to beat. However the payload is disguised, the exploit still has to drive the application to touch a file it shouldn't, and that's what Oligo sees.

Three things follow from that:

1. It catches attacks it hasn't seen before, including zero days, because it looks for behavior that's out of place rather than matching a list of known-bad patterns or known vulnerabilities.
2. It raises fewer false alarms, because it knows what normal looks like. A routine log file being rewritten doesn't get flagged as an attack, so when an alert does fire, it’s worth acting on.
3. Every alert names the exact part of the application involved, so the team receiving it knows what happened, where, and which code to fix.

‍What this looks like in practice

The vulnerable code often isn't even yours. In August 2025, Apache Tika, a document-parsing library built into a wide range of applications and pipelines, disclosed CVE-2025-54988, an XXE (XML external entity) flaw in its PDF parser. A crafted XFA form inside a PDF is all it takes: when Tika extracts the document, its XML parser can be made to open a sensitive file on the server. A follow-up CVE found the flaw reached beyond the PDF module into tika-core itself, and public scanning templates now make it easy to find exposed instances. Any application that accepts an uploaded PDF and hands it to Tika inherits the risk, whether or not the team knows Tika is in the stack.

Picture an attacker uploading a series of crafted PDFs to an application that extracts their text with a vulnerable version of Tika. Each PDF carries an external entity pointing at a different file: /etc/passwd, /etc/shadow, a Kubernetes token, an application secret.

Taken one at a time, every one of those is an ordinary file read. A tool watching file names or process activity sees a Java process reading files, which is what Java processes do. Here's what a process-level tool sees:

process:  java (pid 4121)
event:    file open
path:     /etc/passwd

Oligo catches these reads because of how the files are reached: through XML parsing, inside a web request. It sees the code path that got there:

That’s the difference between seeing a file read and seeing an attack.

What's next

Arbitrary File Access detections are generally available now for Oligo customers running Sensor 5.30 or later. More file and network detections are coming, followed by blocking for these attacks, so Oligo can stop them as well as spot them.

See Oligo ADR in action

A question worth asking yourself or your team: if one of your applications were tricked into reading a credentials file today, would any of your tools tell you which code did it?

If the honest answer is "we'd figure it out eventually," book a demo to see these detections in your environment.