What are the signs that archive containment checks are failing?

What failure looks like when archive containment is unstable

The clearest sign is nondeterminism. A containment check should give the same answer for the same archive and destination every time; when repeated runs sometimes keep extraction inside the target tree and sometimes allow paths to escape, the control is not trustworthy. That inconsistency means the check is racing the filesystem or validating the wrong path representation.

Another warning sign is disagreement between lexical path checks and the filesystem’s actual resolved location. If a path looks safe before extraction but the real filesystem result lands outside the intended directory, the containment logic is being bypassed by resolution rules, symlinks, or directory state changes. A robust check must reason about the path the filesystem will actually use, not just the string that was supplied.

Unexpected EEXIST outcomes are also meaningful. When an archive sometimes collides with pre-existing names, unexpectedly creates outside files or directories, or behaves differently depending on timing, the check may be assuming a stable directory state that no longer exists. That is often a sign the validation step and the write step are not bound tightly enough together.

Why race sensitivity matters more than a one-off bad result

Containment failures are especially dangerous because they often appear only under specific timing or filesystem conditions. A single successful test run does not prove safety if the same archive can escape under load, on a different platform, or after a small change in directory contents. That kind of variability is a control failure, not an edge case.

What matters is whether the archive can be validated once and then written later against a different filesystem state. If an attacker or even a concurrent process can change the target tree between check and write, the archive may traverse outside the intended boundary even though the earlier validation looked correct. The observable symptom is that the safety decision depends on timing rather than on an invariant.

For practical verification, it helps to compare repeated extraction attempts against the same input, under different pre-existing directory states, and with path features that exercise resolution behavior such as nested directories, symlinks, and duplicate names. If the result changes without the archive changing, the containment model is too weak.

How to judge whether the control is actually dependable

A dependable archive containment check should be deterministic, path-accurate, and resistant to state changes between validation and extraction. It should fail closed when the filesystem state is ambiguous rather than guessing. If your review shows that safe and unsafe outcomes both occur from the same archive, treat the control as incomplete even if some test cases pass.

Signs of weakness also include inconsistent handling across environments. Differences between operating systems, filesystems, container runtimes, or archive formats can expose path-resolution assumptions that were not tested. The control only works if its correctness holds in the real deployment environment, not just in a narrow lab setup.

NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because the failure mode is really about integrity, access control, and configuration discipline in a file-processing workflow. For a broader security posture view, NIST Cybersecurity Framework 2.0 helps frame the issue as a protection and detection problem, not just a parsing bug.

Practitioner Guidance

What to verify: Re-run the same archive through the same code path multiple times, then repeat with different pre-existing directory contents. If the outcome changes, the control is not safe enough to trust yet, regardless of a successful single test.

Decision rule: If lexical validation and resolved filesystem location can disagree, treat the implementation as vulnerable until the check and the write step are made atomic or otherwise bound to the same verified path state. Do not accept "usually safe" behavior for a containment control.

Common mistake: Teams often test only the happy path, where the archive expands cleanly into an empty directory. That misses the failure modes that show up when names already exist, when the filesystem resolves links differently, or when concurrent activity changes the tree during extraction.

Practitioner takeaway: The key question is not whether the archive passed once, but whether the same archive can ever produce a different containment decision under realistic filesystem conditions. If it can, the control is not deterministic enough for production use.

Related resources from NHI Mgmt Group

• What are the signs that a backdoored model is failing operational checks?
• What are the signs that an LLM deployment is failing its access-control and leak-prevention checks?
• What are the signs that pnpm-based dependency installation is failing its containment boundary?
• What are the signs that app-store-only age checks are failing in practice?