Disclosure of an issue discovered in SimpleArchiver on 2026-03-18

2026-03-18_disclosure.html

Posted on: https://seodisparate.com/blog/simplearchiver_issue_disclosure/

On the 18th of March, 2026, it was discovered that <b>simplearchiver</b>
was vulnerable to an issue in parsing existing archive files. In particular,
every version of <b>simplearchiver</b> prior to version <b>2.7</b> is
vulnerable.

<br />
<br />

<h3>Some Background</h3>

<a href="https://github.com/Stephen-Seo/SimpleArchiver"><b>simplearchiver</b></a>
can be described as an alternative to <b>tar</b>. It can create archives, and
test/extract them. Note that when testing or extracting a <b>simplearchiver</b>
archive, a binary file is parsed according to the file format specification
<a href="https://github.com/Stephen-Seo/SimpleArchiver/blob/main/file_format.md">(the format of which is specified here)</a>.

<br />
<br />

<h3>The Problem</h3>

The problem discovered in <b>simplearchiver</b> was this: all paths parsed in
the archive file were not validated. Normally, this wouldn't be an issue, since
an archive file created with <b>simplearchiver</b> is always properly created
according to the file format specification. However, such an archive file can be
edited by someone before being distributed to someone else. Again, this also
can be a non-issue since if anything important was being archived, the archive
would've been distributed with a cryptographic hash (like sha256) to verify its
validity.

<br />
<br />

The fix created for version <b>2.7</b> of <b>simplearchiver</b> is to validate
every parsed single filename, directory name, and symbolic link name.
Specifically, it checks if any of these names/strings start with "../", end
with "/..", or has "/../" in between. If such a string exists, then
<b>simplearchiver</b> prints that there was an error, and halts parsing
immediately.

<br />
<br />

<h3>Implications of the Problem</h3>

For those unfamiliar with directory traversal (common on Unix systems), any
path that contains a ".." usually refers to the "previous directory". For
example, say there was the following directory structure:

<pre><code>
outer_dir/
 - inner_dir/
   - another_dir/
</code></pre>

If the current working directory is "another_dir" (by executing a command like
"cd outer_dir/inner_dir/another_dir"), then a command like "ls .." will print
the contents of "inner_dir", and "ls ../.." will print the contents of
"outer_dir".

<br />
<br />

As ".." refers to the previous dir, a command executed (from within
"another_dir") like "echo test > ../../test_file" will create a file called
"test_file" in the "outer_dir" directory.

<br />
<br />

The point is this: If <b>simplearchiver</b> accepted paths that had ".." in
them, then when a maliciously crafted archive is parsed for extraction, it may
create and/or modify files not in the current directory (or the directory
specified by the "-C &#60;dir&#62;" passed to <b>simplearchiver</b>).

<br />
<br />

<h3>Closing Remarks</h3>

Unfortunately, this kind of problem is <a
href="https://github.com/advisories/GHSA-f842-phm9-p4v4">not uncommon</a>.
Software development remains a type of work that is difficult to get things
right, especially on the first time. Luckily, there are <a href="https://valgrind.org/docs/manual/mc-manual.html">tools</a>
to help identify and fix bugs, and there are ways to
<a href="https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html">harden software</a>
to prevent other classes of bugs. It may be somewhat easy to introduce a bug in
one's software, but with the tooling available these days, it may be just as
easy to fix them. We can only hope that when such a bug appears, that it does
not cause a security issue for end-users, and that it is properly identified and
fixed before giving everyone a headache.