@pipeworx/mcp-edge-case-museum 0.1.0 → 0.2.0

package/src/exhibits/filenames/extension-trap-double-extension.json

@@ -1,62 +0,0 @@
-{
-  "id": "extension-trap-double-extension",
-  "title": "splitext(\"archive.tar.gz\") gives you \".gz\", not \".tar.gz\"",
-  "category": "filenames",
-  "assumption": "The 'extension' of a filename is everything after the first dot.",
-  "input": {
-    "display": "\"archive.tar.gz\"",
-    "description": "Any compressed-archive filename, used to decide how to decompress an uploaded or downloaded file."
-  },
-  "what_goes_wrong": "Code that branches on the file's extension to pick a decompressor sees only \".gz\", runs gunzip, and is left holding a .tar file it never un-tars — or mis-identifies the file type entirely.",
-  "why": "Both os.path.splitext and Node's path.extname define 'the extension' as the text from the LAST dot to the end of the string, a deliberate choice so a filename like \"version.1.2.3\" isn't treated as having the extension \".1.2.3\". That same rule means a genuinely double-barreled extension like \".tar.gz\" is reported as just \".gz\"; the \".tar\" part is silently folded into what both functions report as the base name.",
-  "affects": [
-    "python os.path.splitext",
-    "node path.extname",
-    "any 'branch on extension' dispatcher"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import os.path\nprint(os.path.splitext(\"archive.tar.gz\"))\n",
-      "expected_output": "('archive.tar', '.gz')",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "import path from 'node:path';\nconsole.log(path.extname(\"archive.tar.gz\"));\nconsole.log(path.basename(\"archive.tar.gz\", path.extname(\"archive.tar.gz\")));\n",
-      "expected_output": ".gz\narchive.tar",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "For known compound suffixes (.tar.gz, .tar.bz2, .tar.xz, ...), check against an explicit list of multi-part suffixes before falling back to splitext/extname.",
-  "related": [
-    "dotfile-has-no-extension"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: os.path.splitext",
-      "url": "https://docs.python.org/3/library/os.path.html#os.path.splitext"
-    },
-    {
-      "title": "Node.js docs: path.extname",
-      "url": "https://nodejs.org/api/path.html#pathextnamepath"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "parsing",
-    "upload",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "archive.tar.gz"
-      ],
-      "relation": "returns",
-      "expected": ".tar.gz",
-      "note": "An extension detector used to pick a decompressor must recognize compound archive suffixes; splitext/extname alone return only '.gz'."
-    }
-  ]
-}

package/src/exhibits/filenames/filename-length-limits-bytes-not-chars.json

@@ -1,66 +0,0 @@
-{
-  "id": "filename-length-limits-bytes-not-chars",
-  "title": "A 255-byte filename limit fits only 85 Chinese characters",
-  "category": "filenames",
-  "assumption": "A filename length limit measured in characters means you can always fit that many characters, in any script.",
-  "input": {
-    "display": "85 repetitions of U+6587 (文) vs 86 repetitions",
-    "description": "A user-supplied title or display name being used, unmodified, as a filename or as a path component in an export."
-  },
-  "what_goes_wrong": "A filename that looks well under a '255 character' budget by character count can already be AT or OVER the real filesystem limit, because most Linux filesystems enforce the limit in BYTES of the encoded name, and common CJK characters take 3 bytes each in UTF-8.",
-  "why": "ext4 and most other Linux filesystems cap a single path component at 255 bytes, not 255 Unicode code points. A Latin-script name is about one byte per character, so the limit feels like a character limit, but a common CJK character encodes to 3 bytes in UTF-8, so 85 of them consume all 255 bytes and the 86th pushes the name past the limit at a character count of only 86. Windows measures differently again: an NTFS name component is limited to 255 UTF-16 code units, and the Win32 API separately caps the whole path at MAX_PATH (260 characters) unless long-path support is enabled, so a limit tuned for one platform does not carry over to the other.",
-  "affects": [
-    "ext4 / most linux filesystems (255 bytes per component)",
-    "windows (255 utf-16 units per ntfs component; 260-character MAX_PATH for the whole path unless long paths are enabled)"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "s85 = \"\\u6587\" * 85\ns86 = \"\\u6587\" * 86\nprint(len(s85), len(s85.encode(\"utf-8\")))\nprint(len(s86), len(s86.encode(\"utf-8\")))\nprint(len(s86.encode(\"utf-8\")) > 255)\n",
-      "expected_output": "85 255\n86 258\nTrue",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const s85 = \"\\u6587\".repeat(85);\nconst s86 = \"\\u6587\".repeat(86);\nconsole.log(s85.length, Buffer.byteLength(s85, \"utf8\"));\nconsole.log(s86.length, Buffer.byteLength(s86, \"utf8\"));\nconsole.log(Buffer.byteLength(s86, \"utf8\") > 255);\n",
-      "expected_output": "85 255\n86 258\ntrue",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "When checking a filename against a filesystem's length limit, measure the encoded byte length (UTF-8 for Linux) against that filesystem's actual limit, not the character or code-point count, and look up the right number for the right platform instead of reusing '255' everywhere.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Linux kernel docs: ext4 directory entries (255-byte names)",
-      "url": "https://www.kernel.org/doc/html/latest/filesystems/ext4/directory.html"
-    },
-    {
-      "title": "Microsoft Learn: Maximum Path Length Limitation",
-      "url": "https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "length validation",
-    "upload",
-    "i18n",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文"
-      ],
-      "relation": "raises",
-      "note": "86 CJK characters is 258 UTF-8 bytes: a validator enforcing a 255-byte filename limit should reject this even though it is only 86 characters."
-    },
-    {
-      "inputs": [
-        "文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文文"
-      ],
-      "relation": "no_crash",
-      "note": "85 of them is exactly 255 bytes and should be accepted."
-    }
-  ]
-}

package/src/exhibits/filenames/leading-dash-filename-parsed-as-flag.json

@@ -1,67 +0,0 @@
-{
-  "id": "leading-dash-filename-parsed-as-flag",
-  "title": "A file literally named \"-rf\" is not a filename to most command-line tools; it is two flags",
-  "category": "filenames",
-  "assumption": "A string you pass as a filename argument is always interpreted as a filename.",
-  "input": {
-    "display": "\"-rf\"",
-    "description": "A filename generated from user content (a title, a hashtag, a ticket id) that happens to start with a hyphen, then passed as a bare positional argument to a CLI tool or argument parser."
-  },
-  "what_goes_wrong": "A command built as `tool <filename>` with a filename of \"-rf\" is read by the tool's argument parser as options, not a filename. At best the tool errors out; in the classic case, `rm *` in a directory containing a file named \"-rf\" hands that name to rm as an argument, and GNU rm (which accepts options anywhere on the command line) reads it as its own -r and -f flags, so rm deletes the other matched directories recursively and without prompting.",
-  "why": "POSIX-style argument parsers decide whether a token is an option by its first character: a leading '-' (other than a lone \"-\", which conventionally means standard input) marks it as a flag, whatever the program meant that argument to be. Python's argparse applies this rule and refuses \"-rf\" as a positional, exiting with a usage error. Node's util.parseArgs, in its non-strict mode, silently parses it as the two boolean flags r and f and leaves no positional at all; in strict mode it throws on the unknown option. Both accept the same token as a filename once it follows a \"--\" end-of-options marker.",
-  "affects": [
-    "posix-style cli argument parsing (not limited to one language)",
-    "python argparse (rejects a leading-dash positional)",
-    "node util.parseArgs (non-strict: parses it as flags; strict: throws)"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import argparse\nparser = argparse.ArgumentParser()\nparser.add_argument(\"filename\")\ntry:\n    args = parser.parse_args([\"-rf\"])\n    print(\"parsed filename:\", args.filename)\nexcept SystemExit as e:\n    print(\"argparse rejected it as a flag, exit code\", e.code)\n",
-      "expected_output": "argparse rejected it as a flag, exit code 2",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "import { parseArgs } from \"node:util\";\nconst loose = parseArgs({ args: [\"-rf\"], allowPositionals: true, strict: false });\nconsole.log(\"non-strict:\", JSON.stringify(loose));\ntry {\n  parseArgs({ args: [\"-rf\"], allowPositionals: true });\n} catch (e) {\n  console.log(\"strict:\", e.code);\n}\nconst escaped = parseArgs({ args: [\"--\", \"-rf\"], allowPositionals: true });\nconsole.log(\"after --:\", JSON.stringify(escaped.positionals));\n",
-      "expected_output": "non-strict: {\"values\":{\"r\":true,\"f\":true},\"positionals\":[]}\nstrict: ERR_PARSE_ARGS_UNKNOWN_OPTION\nafter --: [\"-rf\"]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "When a value could plausibly start with '-', pass it after a literal `--` end-of-options marker wherever the tool supports one, or prefix it with `./` so it no longer starts with a dash.",
-  "related": [],
-  "sources": [
-    {
-      "title": "POSIX: Utility Syntax Guidelines (Guideline 10, the -- delimiter)",
-      "url": "https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap12.html"
-    },
-    {
-      "title": "GNU C Library: Program Argument Syntax Conventions",
-      "url": "https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html"
-    },
-    {
-      "title": "Python docs: argparse",
-      "url": "https://docs.python.org/3/library/argparse.html"
-    },
-    {
-      "title": "Node.js docs: util.parseArgs",
-      "url": "https://nodejs.org/api/util.html#utilparseargsconfig"
-    }
-  ],
-  "tags": [
-    "filename",
-    "security",
-    "validation",
-    "upload",
-    "parsing"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "-rf"
-      ],
-      "relation": "no_crash",
-      "note": "A generated filename that starts with '-' needs an explicit escape before it reaches a CLI argument list, or it won't be read as a filename at all."
-    }
-  ]
-}

package/src/exhibits/filenames/nfc-nfd-filename-lookup-mismatch.json

@@ -1,68 +0,0 @@
-{
-  "id": "nfc-nfd-filename-lookup-mismatch",
-  "title": "Two filenames that look identical can be different byte strings, and a Linux server will store both",
-  "category": "filenames",
-  "assumption": "A filename that looks the same on screen is the same filename on disk.",
-  "input": {
-    "display": "\"caf\\u00e9.txt\" encoded as NFC (\\u00e9) vs the same visible name encoded as NFD (e + \\u0301)",
-    "description": "A filename that arrives in decomposed form (for example, a file that originated on an older Mac HFS+ volume, which stored names in a variant of NFD, or a client that decomposes text) stored verbatim on a Linux server, then looked up by the composed form a different client produced."
-  },
-  "what_goes_wrong": "A byte-exact filename search for the composed form finds nothing, even though a file with the 'same' visible name exists on disk, because the stored bytes are the decomposed form.",
-  "why": "NFC and NFD are both valid Unicode encodings of identical visible text, but they are different code-point sequences and therefore different UTF-8 bytes. Linux filesystems like ext4 treat names as opaque bytes with no normalization, so the two forms are two unrelated names: a lookup by one misses the other, and both can coexist in one directory. Mac filesystems behave differently: HFS+ stored names in a variant of NFD, while APFS preserves whichever form it was given but matches names normalization-insensitively, so the same lookup that succeeds on a Mac fails once the file is on a Linux server.",
-  "affects": [
-    "ext4 / most linux filesystems (byte-wise names, no normalization)",
-    "macos hfs+ (stores a variant of nfd)",
-    "macos apfs (preserves the given form, normalization-insensitive lookup)",
-    "any client/server pair that disagrees on normalization form"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import unicodedata\nnfc = unicodedata.normalize(\"NFC\", \"caf\\u00e9.txt\")\nnfd = unicodedata.normalize(\"NFD\", \"caf\\u00e9.txt\")\nprint(nfc == nfd, len(nfc), len(nfd))\nprint(nfc.encode(\"utf-8\") == nfd.encode(\"utf-8\"), len(nfc.encode(\"utf-8\")), len(nfd.encode(\"utf-8\")))\n",
-      "expected_output": "False 8 9\nFalse 9 10",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const nfc = \"caf\\u00e9.txt\".normalize(\"NFC\");\nconst nfd = \"caf\\u00e9.txt\".normalize(\"NFD\");\nconsole.log(nfc === nfd, nfc.length, nfd.length);\nconsole.log(Buffer.from(nfc, \"utf8\").equals(Buffer.from(nfd, \"utf8\")), Buffer.byteLength(nfc), Buffer.byteLength(nfd));\n",
-      "expected_output": "false 8 9\nfalse 9 10",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize every filename to one form (NFC is the usual choice) at the point it enters your system, before it ever reaches a save or a lookup, so client and server always agree on the byte sequence.",
-  "related": [
-    "nfc-nfd-same-name-two-accounts"
-  ],
-  "sources": [
-    {
-      "title": "Unicode Standard Annex #15: Unicode Normalization Forms",
-      "url": "https://www.unicode.org/reports/tr15/"
-    },
-    {
-      "title": "Apple Technical Q&A QA1173: Text Encodings in VFS (HFS+ decomposed names)",
-      "url": "https://developer.apple.com/library/archive/qa/qa1173/_index.html"
-    },
-    {
-      "title": "Apple File System Guide: FAQ (APFS normalization and case sensitivity)",
-      "url": "https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "normalization",
-    "upload",
-    "i18n",
-    "unicode"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "café.txt",
-        "café.txt"
-      ],
-      "relation": "equal",
-      "note": "A filename-key function should normalize (usually to NFC) so the composed and decomposed spellings map to the same key."
-    }
-  ]
-}

package/src/exhibits/filenames/ntfs-alternate-data-stream-colon.json

@@ -1,59 +0,0 @@
-{
-  "id": "ntfs-alternate-data-stream-colon",
-  "title": "\"file.txt:hidden\" isn't a second file on NTFS — it's extra data bolted onto file.txt that `dir` will never show you",
-  "category": "filenames",
-  "assumption": "A colon in a filename is just another character, and a name containing one refers to a distinct file.",
-  "input": {
-    "display": "\"file.txt:hidden\"",
-    "description": "A filename accepted from user input (or produced by careless string concatenation) that is later written to an actual NTFS volume."
-  },
-  "what_goes_wrong": "On NTFS, writing to \"file.txt:hidden\" doesn't create a new file — it creates (or overwrites) an alternate data stream attached to the EXISTING file.txt, invisible to a normal directory listing and not counted in the visible file's reported size, so arbitrary extra data can be smuggled in behind an ordinary-looking file.",
-  "why": "NTFS filenames support multiple named 'data streams' per file entry, addressed as \"name:stream\"; the unnamed stream is the file's normal content, and \"file.txt:hidden\" addresses an additional stream on the SAME directory entry as file.txt, not a sibling file. Pure path libraries have no awareness of this NTFS-specific syntax at all — they just see a colon character — so splitext and basename don't special-case it; splitext even folds the whole \":hidden\" suffix into what it reports as the file's 'extension'.",
-  "affects": [
-    "windows ntfs (alternate data streams)",
-    "python ntpath (no ads awareness — colon is just a character)",
-    "node path.win32 (no ads awareness)"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import ntpath\nname = \"file.txt:hidden\"\nprint(\"splitdrive:\", ntpath.splitdrive(name))\nprint(\"splitext:\", ntpath.splitext(name))\nprint(\"basename:\", ntpath.basename(name))\n",
-      "expected_output": "splitdrive: ('', 'file.txt:hidden')\nsplitext: ('file', '.txt:hidden')\nbasename: file.txt:hidden",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "import path from 'node:path';\nconst name = \"file.txt:hidden\";\nconst parsed = path.win32.parse(name);\nconsole.log(\"ext:\", parsed.ext, \"name:\", parsed.name, \"base:\", parsed.base);\n",
-      "expected_output": "ext: .txt:hidden name: file base: file.txt:hidden",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Reject colons in filenames outright before they reach a Windows filesystem unless you specifically intend to address a named stream, and never rely on directory listings or visible file size alone to audit what's actually stored in a file.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Microsoft Sysinternals: Streams (NTFS Alternate Data Streams)",
-      "url": "https://learn.microsoft.com/en-us/sysinternals/downloads/streams"
-    },
-    {
-      "title": "Microsoft Learn: Naming Files, Paths, and Namespaces",
-      "url": "https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "security",
-    "validation",
-    "upload"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "file.txt:hidden"
-      ],
-      "relation": "no_crash",
-      "note": "Your filename validator should reject or specifically handle a colon before it reaches a Windows filesystem call."
-    }
-  ]
-}

package/src/exhibits/filenames/ntpath-splitdrive-unc-paths.json

@@ -1,58 +0,0 @@
-{
-  "id": "ntpath-splitdrive-unc-paths",
-  "title": "A UNC path's \"drive\" isn't a drive letter at all — it's the whole \\\\server\\share",
-  "category": "filenames",
-  "assumption": "splitdrive on a Windows path always returns either nothing or a single letter plus a colon.",
-  "input": {
-    "display": "\"\\\\\\\\server\\\\share\\\\file.txt\" (UNC path) vs \"C:\\\\Users\\\\me\\\\file.txt\"",
-    "description": "A network path (a mapped file server, a backup target) handled by code that was only ever tested against local drive-letter paths."
-  },
-  "what_goes_wrong": "Code that assumes the 'drive' component is either empty or exactly two characters (\"C:\") mishandles a UNC path, truncating or misinterpreting the server/share portion that ntpath actually bundles into the drive.",
-  "why": "ntpath.splitdrive special-cases UNC syntax: for a path starting with two separators followed by a server and share name, it returns the ENTIRE \\\\server\\share prefix as the 'drive', not just a letter and colon, because that whole prefix has to stay together to resolve the rest of the path. Node's path.win32.parse does the analogous thing, putting the full \\\\server\\share\\ into `root`. A function written only against \"C:\" paths, and assuming a fixed two-character drive length, breaks silently on the far longer UNC form.",
-  "affects": [
-    "python ntpath.splitdrive",
-    "node path.win32 (root / parse)",
-    "windows unc paths"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import ntpath\nprint(ntpath.splitdrive(\"C:\\\\Users\\\\me\\\\file.txt\"))\nprint(ntpath.splitdrive(\"\\\\\\\\server\\\\share\\\\file.txt\"))\n",
-      "expected_output": "('C:', '\\\\Users\\\\me\\\\file.txt')\n('\\\\\\\\server\\\\share', '\\\\file.txt')",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "import path from 'node:path';\nconsole.log(path.win32.parse(\"C:\\\\Users\\\\me\\\\file.txt\").root);\nconsole.log(path.win32.parse(\"\\\\\\\\server\\\\share\\\\file.txt\").root);\n",
-      "expected_output": "C:\\\n\\\\server\\share\\",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Use the library's own splitdrive/parse output rather than assuming a fixed-width drive prefix, and test path-handling code against UNC paths explicitly, not just local drive letters.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Microsoft Learn: Naming Files, Paths, and Namespaces (UNC paths)",
-      "url": "https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file"
-    },
-    {
-      "title": "Python docs: os.path (ntpath)",
-      "url": "https://docs.python.org/3/library/os.path.html"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "parsing",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "\\\\server\\share\\file.txt"
-      ],
-      "relation": "no_crash",
-      "note": "If your code assumes a drive component is always empty or exactly 'C:', test it against a UNC path like this one."
-    }
-  ]
-}

package/src/exhibits/filenames/nul-byte-in-filename-raises-at-open.json

@@ -1,60 +0,0 @@
-{
-  "id": "nul-byte-in-filename-raises-at-open",
-  "title": "A filename with an embedded NUL byte sails through every path function, then blows up the moment you open it",
-  "category": "filenames",
-  "assumption": "If os.path.join / path.join didn't raise an error, the filename is safe to use.",
-  "input": {
-    "display": "\"a\\u0000b\" (the letter a, a NUL byte, the letter b)",
-    "description": "A filename decoded from untrusted bytes (a multipart upload, a binary protocol field) that was never validated as a 'reasonable' string before being treated as a filename."
-  },
-  "what_goes_wrong": "String-only path functions accept the NUL byte without complaint and happily build a joined path containing it; the error only appears later, at the actual filesystem call, in a different part of the codebase than where the bad input was first accepted.",
-  "why": "os.path.join and path.join are pure string operations — they concatenate and, in Node's case, normalize separators, but neither inspects the byte content for anything the OS might reject. The OS filesystem call layer represents paths as NUL-terminated C strings, so an embedded NUL byte would truncate or corrupt the path at the syscall level; both Python's open() and Node's fs functions guard against this themselves and raise before making the call, rather than letting the OS ever see a truncated string.",
-  "affects": [
-    "python os.path.join (no validation)",
-    "node path.join (no validation)",
-    "python open() (raises ValueError)",
-    "node fs (raises ERR_INVALID_ARG_VALUE)"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import os.path\njoined = os.path.join(\"a\\x00b\", \"c\")\nprint(\"join accepted it:\", repr(joined))\ntry:\n    open(\"a\\x00b\")\nexcept ValueError as e:\n    print(\"open() raised:\", e)\n",
-      "expected_output": "join accepted it: 'a\\x00b/c'\nopen() raised: embedded null byte",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "import path from 'node:path';\nimport fs from 'node:fs';\nconst joined = path.join(\"a\\0b\", \"c\");\nconsole.log(\"join accepted it:\", JSON.stringify(joined));\ntry {\n  fs.readFileSync(\"a\\0b\");\n} catch (e) {\n  console.log(\"fs raised:\", e.code);\n}\n",
-      "expected_output": "join accepted it: \"a\\u0000b/c\"\nfs raised: ERR_INVALID_ARG_VALUE",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Validate filenames for control characters (including NUL) at the point you accept them, not at the point you happen to open them — the path-building layer in between will not catch it for you.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Python docs: File Names, Command-Line Arguments, and Environment Variables",
-      "url": "https://docs.python.org/3/library/os.html#file-names-command-line-arguments-and-environment-variables"
-    },
-    {
-      "title": "Node.js docs: fs — file paths",
-      "url": "https://nodejs.org/api/fs.html#file-paths"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "validation",
-    "upload",
-    "security"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "a\u0000b"
-      ],
-      "relation": "raises",
-      "note": "Your file-open code should raise here, not silently truncate the filename at the NUL byte."
-    }
-  ]
-}

package/src/exhibits/filenames/path-join-escapes-the-base-directory.json

@@ -1,63 +0,0 @@
-{
-  "id": "path-join-escapes-the-base-directory",
-  "title": "Joining a trusted folder with a filename doesn't confine the result to that folder",
-  "category": "filenames",
-  "assumption": "os.path.join(trusted_base, user_supplied_name) always produces a path inside trusted_base.",
-  "input": {
-    "display": "\"../../etc/passwd\" joined onto \"/srv/uploads\"",
-    "description": "An upload handler or export feature that builds a save path from a base directory plus a user-controlled filename."
-  },
-  "what_goes_wrong": "The joined path points outside the upload directory entirely, letting a crafted filename read or overwrite files the base directory was supposed to contain.",
-  "why": "os.path.join concatenates path segments; it never checks whether a later argument walks back out of the first with `..` components, it just glues the strings together, and the escape only becomes visible once the OS resolves the dots at open time. Node's path.join goes further and actively normalizes `.` and `..` within the joined string itself, so the same escape is visible immediately in the returned string rather than only at the filesystem call. Either way, neither function treats its first argument as a security boundary; it is nothing more than the first string in a concatenation.",
-  "affects": [
-    "python os.path.join",
-    "node path.join",
-    "any 'join the base dir with the filename' upload handler"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import os.path\njoined = os.path.join(\"/srv/uploads\", \"../../etc/passwd\")\nprint(joined)\nprint(joined.startswith(\"/srv/uploads\"))\n",
-      "expected_output": "/srv/uploads/../../etc/passwd\nTrue",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "import path from 'node:path';\nconst joined = path.join(\"/srv/uploads\", \"../../etc/passwd\");\nconsole.log(joined);\nconsole.log(joined.startsWith(\"/srv/uploads\"));\n",
-      "expected_output": "/etc/passwd\nfalse",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "After joining, resolve the result to an absolute, normalized path (os.path.realpath / path.resolve) and verify it still starts with the resolved base directory before touching the filesystem; reject anything that doesn't.",
-  "related": [
-    "absolute-second-argument-resets-join",
-    "windows-backslash-traversal-ntpath"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: os.path.join",
-      "url": "https://docs.python.org/3/library/os.path.html#os.path.join"
-    },
-    {
-      "title": "Node.js docs: path.join",
-      "url": "https://nodejs.org/api/path.html#pathjoinpaths"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "upload",
-    "security",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "/srv/uploads",
-        "../../etc/passwd"
-      ],
-      "relation": "no_crash",
-      "note": "Your path-builder should either refuse this filename or produce a path still inside the base directory — check which, don't assume."
-    }
-  ]
-}

package/src/exhibits/filenames/windows-backslash-traversal-ntpath.json

@@ -1,62 +0,0 @@
-{
-  "id": "windows-backslash-traversal-ntpath",
-  "title": "A traversal filter that only blocks \"../\" misses \"..\\\\\" — and you can test the miss without touching Windows",
-  "category": "filenames",
-  "assumption": "Checking a filename for the substring \"../\" catches every directory-traversal attempt.",
-  "input": {
-    "display": "\"..\\\\..\\\\windows\\\\system32\" (backslash-separated traversal)",
-    "description": "A filename accepted by a web form where the server later resolves the path on Windows, or a ZIP/tar entry name that uses backslashes."
-  },
-  "what_goes_wrong": "A blocklist written against the forward-slash form lets the backslash form straight through, and ntpath/path.win32 — which treat backslash as the canonical separator — walk back out of the intended directory exactly as the forward-slash form would.",
-  "why": "ntpath and path.win32 are pure-path implementations of Windows' own path rules, where backslash is the primary separator even though forward slash also works. A traversal check written only against the string \"../\" is really checking for a POSIX idiom and has nothing to say about \"..\\\\\", so on any code path that eventually resolves the string as a Windows path, the backslash form reaches the same `..` component and climbs out of the base directory just the same.",
-  "affects": [
-    "windows path resolution (backslash is the canonical separator)",
-    "ntpath (runs on any host, not just windows)",
-    "path.win32 (runs on any host, not just windows)"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import ntpath\nraw = \"..\\\\..\\\\windows\\\\system32\"\nprint(\"contains ../ :\", \"../\" in raw)\njoined = ntpath.join(\"C:\\\\srv\\\\uploads\", raw)\nprint(\"joined:\", joined)\nprint(\"normalized:\", ntpath.normpath(joined))\n",
-      "expected_output": "contains ../ : False\njoined: C:\\srv\\uploads\\..\\..\\windows\\system32\nnormalized: C:\\windows\\system32",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "import path from 'node:path';\nconst raw = \"..\\\\..\\\\windows\\\\system32\";\nconsole.log(\"contains ../ :\", raw.includes(\"../\"));\nconst joined = path.win32.join(\"C:\\\\srv\\\\uploads\", raw);\nconsole.log(\"joined:\", joined);\n",
-      "expected_output": "contains ../ : false\njoined: C:\\windows\\system32",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize with the platform-appropriate path module and compare the RESULT against the resolved base directory; never pattern-match the raw string for one separator style.",
-  "related": [
-    "path-join-escapes-the-base-directory"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: os.path (ntpath on Windows)",
-      "url": "https://docs.python.org/3/library/os.path.html"
-    },
-    {
-      "title": "Node.js docs: path.win32",
-      "url": "https://nodejs.org/api/path.html#pathwin32"
-    }
-  ],
-  "tags": [
-    "filename",
-    "path",
-    "security",
-    "validation",
-    "upload"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "C:\\srv\\uploads",
-        "..\\..\\windows\\system32"
-      ],
-      "relation": "no_crash",
-      "note": "A traversal filter tested only against forward slashes should also be tested against this backslash form before you trust it."
-    }
-  ]
-}