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

package/src/exhibits/parsing/csv-formula-injection-excel.json

@@ -1,71 +0,0 @@
-{
-  "id": "csv-formula-injection-excel",
-  "title": "A CSV cell that parses as a harmless string can still execute as a formula the moment someone opens it in Excel",
-  "category": "parsing",
-  "assumption": "If a CSV parser reads a cell's value back as the exact literal string that was written, the value is safe wherever the file ends up.",
-  "input": {
-    "display": "name,amount\\n\"=cmd|' /C calc'!A0\",100\\n",
-    "description": "User-controlled text (a name, a comment, an address) exported into a CSV/XLSX that will be opened by a human in Excel, Google Sheets, or LibreOffice Calc - any cell value beginning with `=`, `+`, `-`, or `@` is a candidate formula to a spreadsheet application."
-  },
-  "what_goes_wrong": "A CSV writer/reader round-trips the attacker's string perfectly and faithfully - the field comes back exactly as `=cmd|' /C calc'!A0` - so nothing in the CSV layer looks wrong. But a spreadsheet application opening that same file treats any cell starting with `=`, `+`, `-`, or `@` as a formula to evaluate, which in older Excel versions could shell out via DDE (`cmd|...!A0`) or exfiltrate data to a remote URL through functions like `IMPORTXML` in Sheets - entirely outside what CSV parsing itself can see or prevent.",
-  "why": "CSV has no concept of formulas; a cell is just delimited text. The danger is downstream: spreadsheet applications overload CSV as an import format for their own formula language, and that interpretation triggers on specific leading characters regardless of what the data \"means\" to your application. OWASP catalogs this as CSV Injection - the fix lives entirely on the writer side (how you emit values a spreadsheet will later open), because the CSV format and a conformant CSV parser are both working exactly as specified.",
-  "affects": [
-    "python",
-    "javascript",
-    "any CSV exported for a human to open in a spreadsheet application"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import csv, io\n\ndef sanitize(value):\n    if isinstance(value, str) and value and value[0] in (\"=\", \"+\", \"-\", \"@\"):\n        return \"'\" + value\n    return value\n\npayload = '=cmd|\\' /C calc\\'!A0'\nraw = io.StringIO()\ncsv.writer(raw).writerow([\"name\", \"amount\"])\ncsv.writer(raw).writerow([payload, \"100\"])\nprint(repr(raw.getvalue()))\nparsed = list(csv.reader(io.StringIO(raw.getvalue())))\nprint(parsed[1][0] == payload)\n\nsafe = io.StringIO()\ncsv.writer(safe).writerow([sanitize(payload), \"100\"])\nprint(repr(safe.getvalue()))\n",
-      "expected_output": "\"name,amount\\r\\n=cmd|' /C calc'!A0,100\\r\\n\"\nTrue\n\"'=cmd|' /C calc'!A0,100\\r\\n\"",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "function sanitize(value) {\n  if (typeof value === \"string\" && value.length && \"=+-@\".includes(value[0])) return \"'\" + value;\n  return value;\n}\nconst payload = \"=cmd|' /C calc'!A0\";\nconsole.log(sanitize(payload));\nconsole.log(sanitize(\"100\"));\nconsole.log(sanitize(\"Smith\"));\n",
-      "expected_output": "'=cmd|' /C calc'!A0\n100\nSmith",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Prefix any user-controlled cell value that starts with `=`, `+`, `-`, or `@` (and, in some guidance, tab or carriage return) with a single quote or another neutralizing character before writing it to a file a human will open in a spreadsheet. Parsing the CSV correctly is necessary but not sufficient - the sanitization has to happen on write, aimed at the spreadsheet application's behavior, not the CSV format's.",
-  "related": [
-    "csv-doubled-quote-escaping"
-  ],
-  "sources": [
-    {
-      "title": "OWASP: CSV Injection",
-      "url": "https://owasp.org/www-community/attacks/CSV_Injection"
-    },
-    {
-      "title": "Python docs: csv - CSV File Reading and Writing",
-      "url": "https://docs.python.org/3/library/csv.html"
-    }
-  ],
-  "tags": [
-    "csv",
-    "upload",
-    "parsing",
-    "security",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "name,amount\n\"=cmd|' /C calc'!A0\",100\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "name",
-          "amount"
-        ],
-        [
-          "=cmd|' /C calc'!A0",
-          "100"
-        ]
-      ],
-      "note": "A CSV-upload parser must return the cell exactly as written - the defence belongs on the export side (prefix values starting with =, +, -, @ with a single quote before writing a file a human will open in a spreadsheet), not in silently altering parsed data."
-    }
-  ]
-}

package/src/exhibits/parsing/csv-quoted-field-with-comma.json

@@ -1,70 +0,0 @@
-{
-  "id": "csv-quoted-field-with-comma",
-  "title": "line.split(\",\") turns one quoted name into two broken columns",
-  "category": "parsing",
-  "assumption": "Splitting a CSV line on \",\" gives you the row's fields.",
-  "input": {
-    "display": "name,amount\\n\"Smith, John\",100\\n",
-    "description": "An uploaded CSV where a free-text field - a person's name written \"Last, First\", a street address, a product description - itself contains a comma, which RFC 4180 quoting exists specifically to protect."
-  },
-  "what_goes_wrong": "`line.split(\",\")` on the data row produces three fields - `'\"Smith'`, `' John\"'`, `'100'` - instead of the two the row actually has, shifting every later naive-split column over by one.",
-  "why": "A comma inside a quoted field is data, not a delimiter - RFC 4180 (and every real CSV dialect) says a field wrapped in double quotes can contain commas, newlines, or anything else, and the quotes are what tells a parser to stop treating that comma as a separator. `str.split(\",\")` has no concept of quoting; it is a dumb character split, so it breaks the field at the comma regardless of the surrounding quotes. A real CSV parser (Python's `csv` module) tracks quote state and only splits on commas outside quotes.",
-  "affects": [
-    "javascript",
-    "any naive split(\",\") CSV parser"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import csv, io\ntext = 'name,amount\\n\"Smith, John\",100\\n'\nnaive = [line.split(\",\") for line in text.splitlines()]\nprint(naive)\nproper = list(csv.reader(io.StringIO(text)))\nprint(proper)\n",
-      "expected_output": "[['name', 'amount'], ['\"Smith', ' John\"', '100']]\n[['name', 'amount'], ['Smith, John', '100']]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const text = 'name,amount\\n\"Smith, John\",100\\n';\nconst naive = text.trim().split(\"\\n\").map(line => line.split(\",\"));\nconsole.log(JSON.stringify(naive));\n",
-      "expected_output": "[[\"name\",\"amount\"],[\"\\\"Smith\",\" John\\\"\",\"100\"]]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never parse CSV with split(\",\"). Use a real CSV parser - Python's stdlib `csv` module, or a maintained library in JS (there is no CSV parser in the JS standard library) - that understands RFC 4180 quoting.",
-  "related": [
-    "csv-quoted-field-with-newline",
-    "csv-doubled-quote-escaping"
-  ],
-  "sources": [
-    {
-      "title": "RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files",
-      "url": "https://www.rfc-editor.org/rfc/rfc4180"
-    },
-    {
-      "title": "Python docs: csv - CSV File Reading and Writing",
-      "url": "https://docs.python.org/3/library/csv.html"
-    }
-  ],
-  "tags": [
-    "csv",
-    "upload",
-    "parsing",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "name,amount\n\"Smith, John\",100\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "name",
-          "amount"
-        ],
-        [
-          "Smith, John",
-          "100"
-        ]
-      ],
-      "note": "A CSV-parsing function given this text must return two rows of two fields each, with the comma inside the quoted name preserved as part of that field's value."
-    }
-  ]
-}

package/src/exhibits/parsing/csv-quoted-field-with-newline.json

@@ -1,70 +0,0 @@
-{
-  "id": "csv-quoted-field-with-newline",
-  "title": "Splitting a CSV file into lines first breaks a row that has a quoted newline in it",
-  "category": "parsing",
-  "assumption": "Each line of a CSV file is one row, so splitting the file on newlines before parsing fields is safe.",
-  "input": {
-    "display": "name,note\\n\"Smith\",\"Line1\\nLine2\"\\n",
-    "description": "A CSV export of a notes or address field that contains an embedded newline (a multi-line note, a two-line mailing address) wrapped in quotes, as RFC 4180 requires."
-  },
-  "what_goes_wrong": "Splitting the raw text into lines first (`text.splitlines()` in Python, `text.split(\"\\n\")` in JS) turns one logical two-field row into three separate \"lines\" - the quoted field's embedded newline is treated as a row boundary before the quoting is ever examined, so no amount of comma-aware parsing afterward can put the row back together.",
-  "why": "RFC 4180 allows a quoted field to contain literal newline characters as part of its value - a row boundary is only the newline that appears outside a quoted field. A real CSV parser (Python's `csv` module) reads character by character and tracks whether it is currently inside a quote, so it does not treat a newline as a row separator while inside quotes. Pre-splitting the text into lines with `splitlines()`/`split(\"\\n\")` throws that context away before the parser ever runs, so the damage is already done.",
-  "affects": [
-    "javascript",
-    "any CSV handling that splits into lines before parsing fields"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import csv, io\ntext = 'name,note\\n\"Smith\",\"Line1\\nLine2\"\\n'\nprint(text.splitlines())\nnaive = [line.split(\",\") for line in text.splitlines()]\nprint(naive)\nproper = list(csv.reader(io.StringIO(text)))\nprint(proper)\n",
-      "expected_output": "['name,note', '\"Smith\",\"Line1', 'Line2\"']\n[['name', 'note'], ['\"Smith\"', '\"Line1'], ['Line2\"']]\n[['name', 'note'], ['Smith', 'Line1\\nLine2']]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const text = 'name,note\\n\"Smith\",\"Line1\\nLine2\"\\n';\nconst naiveLines = text.split(\"\\n\");\nconsole.log(JSON.stringify(naiveLines));\n",
-      "expected_output": "[\"name,note\",\"\\\"Smith\\\",\\\"Line1\",\"Line2\\\"\",\"\"]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Never split a CSV file into lines before parsing fields. Hand the whole text (or a stream) to a real quote-aware CSV parser - Python's `csv.reader`, or a maintained CSV library in JS - and let it decide where rows actually end.",
-  "related": [
-    "csv-quoted-field-with-comma",
-    "csv-doubled-quote-escaping"
-  ],
-  "sources": [
-    {
-      "title": "RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files",
-      "url": "https://www.rfc-editor.org/rfc/rfc4180"
-    },
-    {
-      "title": "Python docs: csv - CSV File Reading and Writing",
-      "url": "https://docs.python.org/3/library/csv.html"
-    }
-  ],
-  "tags": [
-    "csv",
-    "upload",
-    "parsing",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "name,note\n\"Smith\",\"Line1\nLine2\"\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "name",
-          "note"
-        ],
-        [
-          "Smith",
-          "Line1\nLine2"
-        ]
-      ],
-      "note": "A CSV-parsing function given this text must return two rows, with the embedded newline preserved inside the second field's value rather than splitting into three rows."
-    }
-  ]
-}

package/src/exhibits/parsing/csv-semicolon-delimited-european-excel.json

@@ -1,70 +0,0 @@
-{
-  "id": "csv-semicolon-delimited-european-excel",
-  "title": "A \"CSV\" from a European Excel is delimited with semicolons, and a comma-delimiter parser reads the whole line as one field",
-  "category": "parsing",
-  "assumption": "A file with a .csv extension is comma-delimited.",
-  "input": {
-    "display": "name;age\\nAda;30\\n",
-    "description": "A CSV exported by Excel configured for a locale (most of continental Europe) where the decimal comma is the default decimal separator - Excel then uses a semicolon as the list/field separator instead of a comma, to avoid colliding with decimal commas in numeric fields, while still naming the file .csv."
-  },
-  "what_goes_wrong": "Parsing this file with a comma-delimited reader produces one single-column row per line - `['name;age']`, `['Ada;30']` - instead of the two columns the file actually has; every downstream column lookup by index or name silently gets the wrong (and only) field.",
-  "why": "\".csv\" names a family of delimited-text formats, not a guarantee of which character is the delimiter. When Excel on Windows saves as CSV it uses the operating system's regional \"list separator\" setting, and in locales whose decimal separator is a comma (most of continental Europe) that setting defaults to a semicolon, so numbers like 3,5 don't collide with the field separator. The file still gets the same \".csv\" extension. A parser that hardcodes `delimiter=\",\"` has no way to detect this from the extension alone.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import csv, io\ntext = 'name;age\\nAda;30\\n'\nprint(list(csv.reader(io.StringIO(text))))\nprint(list(csv.reader(io.StringIO(text), delimiter=\";\")))\n",
-      "expected_output": "[['name;age'], ['Ada;30']]\n[['name', 'age'], ['Ada', '30']]",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const text = \"name;age\\nAda;30\\n\";\nconst commaDelimited = text.trim().split(\"\\n\").map(line => line.split(\",\"));\nconst semicolonDelimited = text.trim().split(\"\\n\").map(line => line.split(\";\"));\nconsole.log(JSON.stringify(commaDelimited));\nconsole.log(JSON.stringify(semicolonDelimited));\n",
-      "expected_output": "[[\"name;age\"],[\"Ada;30\"]]\n[[\"name\",\"age\"],[\"Ada\",\"30\"]]",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Sniff the delimiter instead of hardcoding it - Python's `csv.Sniffer().sniff(sample)` guesses it from a sample of the file, or check the first line for the most frequent of `,`, `;`, and `\\t` before choosing a reader. Let users confirm the detected delimiter on upload rather than failing silently.",
-  "related": [
-    "csv-utf8-bom-first-header"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: csv.Sniffer",
-      "url": "https://docs.python.org/3/library/csv.html#csv.Sniffer"
-    },
-    {
-      "title": "RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files",
-      "url": "https://www.rfc-editor.org/rfc/rfc4180"
-    }
-  ],
-  "tags": [
-    "csv",
-    "upload",
-    "parsing",
-    "i18n",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "name;age\nAda;30\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "name",
-          "age"
-        ],
-        [
-          "Ada",
-          "30"
-        ]
-      ],
-      "note": "A CSV-parsing function that auto-detects the delimiter should return two columns for this semicolon-delimited file, not one column containing the whole line."
-    }
-  ]
-}

package/src/exhibits/parsing/csv-utf8-bom-first-header.json

@@ -1,74 +0,0 @@
-{
-  "id": "csv-utf8-bom-first-header",
-  "title": "A CSV header named \"name\" comes back as \"\\ufeffname\" and every lookup by column name fails",
-  "category": "parsing",
-  "assumption": "Decoding an uploaded CSV file as UTF-8 and reading its first header exactly recovers the column name the file's first line shows on screen.",
-  "input": {
-    "display": "bytes: EF BB BF 6e 61 6d 65 2c 61 67 65 0a 41 64 61 2c 33 30 0a (\"\\ufeffname,age\\nAda,30\\n\")",
-    "description": "A CSV saved from Excel with the \"CSV UTF-8 (Comma delimited)\" format (and by many other Windows tools), which writes a UTF-8 byte-order mark at the very start of the file - invisible in a spreadsheet and in most text editors, but present as real bytes. (Excel's plain \"CSV (Comma delimited)\" format writes no BOM, and uses the system code page rather than UTF-8.)"
-  },
-  "what_goes_wrong": "Decoding the file's bytes as plain `\"utf-8\"` leaves the BOM as a literal U+FEFF character glued onto the first header, so the first column parses as `\"\\ufeffname\"` instead of `\"name\"` - a lookup like `row[\"name\"]` throws a KeyError even though the column is clearly named \"name\" in every spreadsheet viewer.",
-  "why": "A UTF-8 BOM is three specific bytes (EF BB BF) that some encoders prepend to mark a file as UTF-8; it decodes to the single code point U+FEFF. Decoding with Python's `\"utf-8\"` codec or Node's `Buffer.toString(\"utf8\")` passes that code point through unchanged as the first character of the text. Python's `\"utf-8-sig\"` codec, and JavaScript's `TextDecoder(\"utf-8\")` (whose spec-default `ignoreBOM: false` means the BOM *is* processed/stripped, despite the confusing name), both detect and strip a leading BOM - but only if you use them instead of the plain decoder.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "raw = '\\ufeffname,age\\nAda,30\\n'.encode(\"utf-8\")\nimport csv, io\nplain = raw.decode(\"utf-8\")\nsig = raw.decode(\"utf-8-sig\")\nprint(list(csv.reader(io.StringIO(plain)))[0])\nprint(list(csv.reader(io.StringIO(sig)))[0])\n",
-      "expected_output": "['\\ufeffname', 'age']\n['name', 'age']",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const bytes = Buffer.from(\"\\ufeffname,age\\nAda,30\\n\", \"utf8\");\nconst plain = bytes.toString(\"utf8\");\nconst stripped = new TextDecoder(\"utf-8\").decode(bytes);\nconsole.log(JSON.stringify(plain.split(\",\")[0]));\nconsole.log(JSON.stringify(stripped.split(\",\")[0]));\n",
-      "expected_output": "\"name\"\n\"name\"",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Decode uploaded CSV/text files with `encoding=\"utf-8-sig\"` in Python (it strips a BOM if present and is a no-op if absent), or use `TextDecoder(\"utf-8\")` (not a raw `Buffer.toString`) in Node, which strips the BOM by default. Alternatively, explicitly strip a leading `\\ufeff` from the decoded text before parsing.",
-  "related": [
-    "csv-crlf-trailing-blank-line"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: codecs - encodings and Unicode (utf-8-sig)",
-      "url": "https://docs.python.org/3/library/codecs.html#encodings-and-unicode"
-    },
-    {
-      "title": "WHATWG Encoding Standard: UTF-8 decoder (BOM handling)",
-      "url": "https://encoding.spec.whatwg.org/#utf-8-decoder"
-    },
-    {
-      "title": "MDN: TextDecoder() constructor (ignoreBOM option)",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder/TextDecoder"
-    }
-  ],
-  "tags": [
-    "csv",
-    "upload",
-    "parsing",
-    "validation",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "name,age\nAda,30\n"
-      ],
-      "relation": "returns",
-      "expected": [
-        [
-          "name",
-          "age"
-        ],
-        [
-          "Ada",
-          "30"
-        ]
-      ],
-      "note": "A CSV-parsing function given text starting with a BOM character should strip it, so the header reads exactly \"name\" rather than \"\\ufeffname\"."
-    }
-  ]
-}

package/src/exhibits/parsing/email-regex-rejects-valid-apostrophe-address.json

@@ -1,68 +0,0 @@
-{
-  "id": "email-regex-rejects-valid-apostrophe-address",
-  "title": "A common signup-form email regex rejects o'brien@example.com but accepts user+tag@example.com",
-  "category": "parsing",
-  "assumption": "A regex like ^[\\w.+-]+@[\\w-]+\\.[a-zA-Z]{2,}$ is a reasonable, slightly-strict stand-in for \"is this a valid email address\".",
-  "input": {
-    "display": "o'brien@example.com",
-    "description": "A signup, checkout, or newsletter form's email field, validated client- or server-side with a hand-written regex, used by a person whose email address's local part (the part before @) contains a punctuation character the regex author didn't anticipate - most commonly an apostrophe in a surname."
-  },
-  "what_goes_wrong": "`/^[\\w.+-]+@[\\w-]+\\.[a-zA-Z]{2,}$/` rejects `o'brien@example.com` (valid, real-world mail address) while accepting `user+tag@example.com` (plus-addressing, also valid) - the regex's author remembered to allow `+` for Gmail-style tagging but not `'`, so a real customer's real address bounces at the form while a less common but equally valid syntax sails through.",
-  "why": "RFC 5322 section 3.2.3 defines the characters allowed in an unquoted local-part (`atext`) as letters, digits and `! # $ % & ' * + - / = ? ^ _ ` { | } ~`, so the apostrophe is exactly as legal as `+` (a dot is also allowed, but only between such characters). A regex built from `\\w` (letters, digits, underscore) plus a hand-picked handful of extras will inevitably miss some of that list, and the apostrophe is a costly one to miss because it appears in real surnames such as O'Brien and D'Angelo, so the regex rejects real customers rather than malformed input.",
-  "affects": [
-    "python",
-    "javascript",
-    "any email validator built from a hand-picked character class instead of RFC 5322's atext"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "const common = /^[\\w.+-]+@[\\w-]+\\.[a-zA-Z]{2,}$/;\nconsole.log(common.test(\"obrien@example.com\"));\nconsole.log(common.test(\"o'brien@example.com\"));\nconsole.log(common.test(\"user+tag@example.com\"));\n",
-      "expected_output": "true\nfalse\ntrue",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "import re\ncommon = re.compile(r\"^[\\w.+-]+@[\\w-]+\\.[a-zA-Z]{2,}$\")\nprint(bool(common.match(\"obrien@example.com\")))\nprint(bool(common.match(\"o'brien@example.com\")))\nprint(bool(common.match(\"user+tag@example.com\")))\n",
-      "expected_output": "True\nFalse\nTrue",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Don't hand-roll an email-syntax regex. Validate only loosely for form UX (e.g. \"contains exactly one @, with non-whitespace on both sides\") and rely on the actual downstream proof that matters - whether sending a confirmation email to the address succeeds - rather than a regex meant to approximate RFC 5322's full grammar.",
-  "related": [],
-  "sources": [
-    {
-      "title": "RFC 5322: Internet Message Format, Section 3.2.3 (Atom / atext)",
-      "url": "https://www.rfc-editor.org/rfc/rfc5322#section-3.2.3"
-    },
-    {
-      "title": "RFC 5321: Simple Mail Transfer Protocol, Section 4.1.2 (Mailbox local-part)",
-      "url": "https://www.rfc-editor.org/rfc/rfc5321#section-4.1.2"
-    }
-  ],
-  "tags": [
-    "email",
-    "validation",
-    "forms",
-    "parsing",
-    "names"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "o'brien@example.com"
-      ],
-      "relation": "returns",
-      "expected": true,
-      "note": "their_is_valid_email(address) should accept this RFC-5322-legal address rather than rejecting it for containing an apostrophe."
-    },
-    {
-      "inputs": [
-        "user+tag@example.com"
-      ],
-      "relation": "returns",
-      "expected": true,
-      "note": "Plus-addressing is also legal atext and should be accepted."
-    }
-  ]
-}

package/src/exhibits/parsing/json-big-integer-precision-loss.json

@@ -1,65 +0,0 @@
-{
-  "id": "json-big-integer-precision-loss",
-  "title": "JSON.parse silently changes a 17-digit integer ID to a different number",
-  "category": "parsing",
-  "assumption": "Parsing a JSON number that looks like an integer gives back that exact integer, as long as the JSON text itself is well-formed.",
-  "input": {
-    "display": "{\"id\": 9007199254740993}",
-    "description": "A large numeric ID - a Snowflake-style ID, a 64-bit database primary key, a big serial number - serialized as a JSON number (not a string) by a backend and consumed by a JavaScript client."
-  },
-  "what_goes_wrong": "`JSON.parse('{\"id\": 9007199254740993}').id` returns `9007199254740992` - one less than the actual ID - and re-serializing it with `JSON.stringify` writes back the wrong, rounded value. Python's `json.loads` on the identical text keeps the exact integer.",
-  "why": "JavaScript's JSON implementation stores every number as the same IEEE-754 double that all JS Numbers use, and doubles can only represent integers exactly up to 2**53 (9,007,199,254,740,992); 9007199254740993 is one past that boundary and rounds to the nearest representable double, which happens to be the even number below it. Python's `json` module parses an integer-looking JSON number into a native arbitrary-precision `int`, which has no such ceiling, so it round-trips exactly.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "const o = JSON.parse('{\"id\": 9007199254740993}');\nconsole.log(o.id);\nconsole.log(o.id === 9007199254740993);\nconsole.log(JSON.stringify(o));\n",
-      "expected_output": "9007199254740992\ntrue\n{\"id\":9007199254740992}",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "import json\no = json.loads('{\"id\": 9007199254740993}')\nprint(o[\"id\"])\nprint(o[\"id\"] == 9007199254740993)\n",
-      "expected_output": "9007199254740993\nTrue",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Serialize any integer that might exceed 2**53 as a JSON string, not a JSON number, and parse it on the JS side with `BigInt(str)` rather than `JSON.parse`'s default Number conversion. Many JSON APIs for 64-bit IDs (e.g. Twitter/X's `id_str`) already do this for exactly this reason.",
-  "related": [
-    "max-safe-integer-plus-two"
-  ],
-  "sources": [
-    {
-      "title": "MDN: Number.MAX_SAFE_INTEGER",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER"
-    },
-    {
-      "title": "MDN: JSON.parse()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse"
-    },
-    {
-      "title": "Python docs: json - JSON encoder and decoder",
-      "url": "https://docs.python.org/3/library/json.html"
-    }
-  ],
-  "tags": [
-    "json",
-    "parsing",
-    "id",
-    "validation"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "{\"id\": 9007199254740993}"
-      ],
-      "relation": "returns",
-      "expected": {
-        "id": 9007199254740993
-      },
-      "note": "their_parse(json_text) must preserve this exact integer id - if it goes through JS's Number type anywhere in the pipeline, it will silently become 9007199254740992."
-    }
-  ]
-}

package/src/exhibits/parsing/json-duplicate-keys-last-wins.json

@@ -1,64 +0,0 @@
-{
-  "id": "json-duplicate-keys-last-wins",
-  "title": "A JSON object with the same key twice parses fine - and silently keeps only the last one",
-  "category": "parsing",
-  "assumption": "A JSON parser rejects (or at least warns about) an object literal that repeats a key, the way a careful reviewer would.",
-  "input": {
-    "display": "{\"a\":1,\"a\":2}",
-    "description": "A JSON payload assembled by string concatenation, a buggy serializer, or a merge of two partial objects that happens to repeat a key - e.g. a webhook payload built from two code paths that both set `\"status\"`."
-  },
-  "what_goes_wrong": "Both Python's `json.loads` and JavaScript's `JSON.parse` accept `{\"a\":1,\"a\":2}` without error and return `{\"a\": 2}` - the first value is discarded with no warning, exception, or trace that the input ever had a conflict.",
-  "why": "The JSON grammar (RFC 8259 section 4) does not forbid duplicate names in an object: names SHOULD be unique, and when they aren't, the RFC says the behaviour of receiving software is unpredictable. The two languages then pin it down themselves. ECMA-262 specifies that `JSON.parse` overwrites a lexically earlier value with a later one for the same key, so last-wins is guaranteed in every conforming JavaScript engine. Python's `json` module documents the same choice: it does not raise and keeps only the last name/value pair. Other parsers in other languages may keep the first value or reject the document, which is how two services can read different values from the same payload.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import json\nprint(json.loads('{\"a\":1,\"a\":2}'))\n",
-      "expected_output": "{'a': 2}",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "console.log(JSON.parse('{\"a\":1,\"a\":2}'));\n",
-      "expected_output": "{ a: 2 }",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Detect duplicates explicitly where they matter. In Python, pass `object_pairs_hook` to `json.loads` and raise if a key repeats; in JavaScript, `JSON.parse` cannot report duplicates, so use a streaming/tokenizing parser that can, or reject them at the producer. Don't assume a successfully-parsed object had exactly the keys the sender wrote.",
-  "related": [],
-  "sources": [
-    {
-      "title": "RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, Section 4",
-      "url": "https://www.rfc-editor.org/rfc/rfc8259#section-4"
-    },
-    {
-      "title": "Python docs: json - JSON encoder and decoder",
-      "url": "https://docs.python.org/3/library/json.html"
-    },
-    {
-      "title": "ECMA-262: JSON.parse",
-      "url": "https://tc39.es/ecma262/#sec-json.parse"
-    }
-  ],
-  "tags": [
-    "json",
-    "parsing",
-    "validation",
-    "security"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "{\"a\":1,\"a\":2}"
-      ],
-      "relation": "returns",
-      "expected": {
-        "a": 2
-      },
-      "note": "their_parse(json_text) on an object with a repeated key returns the last value under standard parsers - if two upstream systems disagree about which value should win, catch this before trusting the parsed result."
-    }
-  ]
-}

package/src/exhibits/parsing/json-lone-surrogate-roundtrip.json

@@ -1,58 +0,0 @@
-{
-  "id": "json-lone-surrogate-roundtrip",
-  "title": "JSON.parse happily accepts a string with an unpaired surrogate - and converting it to UTF-8 corrupts or crashes later",
-  "category": "parsing",
-  "assumption": "If JSON.parse (or json.loads) accepts a string without error, that string is well-formed Unicode text that any later encoding step will handle safely.",
-  "input": {
-    "display": "\"\\ud800\" (a lone UTF-16 high surrogate, with no matching low surrogate)",
-    "description": "A string field corrupted upstream - a truncated emoji or CJK character cut exactly between its two surrogate halves, or data copied out of a UTF-16 source (e.g. a Windows filename or a Java/C# string) that already contained an unpaired surrogate - serialized into a JSON payload via a \\u escape."
-  },
-  "what_goes_wrong": "Both `JSON.parse` and Python's `json.loads` accept the escape `\\ud800` and hand back a string containing that single unpaired surrogate, with no error. The corruption surfaces later and differently in each language: encoding that Python string to UTF-8 raises `UnicodeEncodeError`, while in Node, `Buffer.from(s, \"utf8\")` silently replaces the lone surrogate with the U+FFFD replacement character - no exception, no warning, just a quietly different byte sequence than the one sent.",
-  "why": "JSON strings are defined over Unicode code points via `\\uXXXX` escapes, and RFC 8259 section 8.2 explicitly notes that the grammar allows an escape for a lone surrogate, leaving the behaviour of receiving software unpredictable - a parser that checks syntax is not required to check that the resulting text is well-formed Unicode. JavaScript strings are UTF-16 code unit sequences and can hold an unpaired surrogate without complaint, so `JSON.parse`/`JSON.stringify` round-trip it fine as a JS value. Python `str` objects are sequences of Unicode code points (including surrogates, which Python represents but which are not valid scalar values), so `json.loads` accepts the escape too - the failure only appears once something tries to encode that code point as actual UTF-8 bytes, because UTF-8 has no legal encoding for a surrogate on its own.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import json\ns = json.loads('\"\\\\ud800\"')\nprint(len(s), hex(ord(s)))\ntry:\n    s.encode(\"utf-8\")\nexcept UnicodeEncodeError as e:\n    print(\"UnicodeEncodeError:\", e)\n",
-      "expected_output": "1 0xd800\nUnicodeEncodeError: 'utf-8' codec can't encode character '\\ud800' in position 0: surrogates not allowed",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const s = JSON.parse('\"\\\\ud800\"');\nconsole.log(s.length, s.charCodeAt(0).toString(16));\nconsole.log(JSON.stringify(s));\nconst buf = Buffer.from(s, \"utf8\");\nconsole.log(buf.toString(\"hex\"), buf.length);\n",
-      "expected_output": "1 d800\n\"\\ud800\"\nefbfbd 3",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Check that decoded JSON strings are well-formed Unicode before re-encoding them: in Python, `s.encode(\"utf-8\")` (strict) raises on a lone surrogate; in JavaScript, `s.isWellFormed()` (Node 20+, ES2024) returns false for it, and `s.toWellFormed()` substitutes U+FFFD explicitly. Do this before `Buffer.from(s, \"utf8\")`, which substitutes silently.",
-  "related": [],
-  "sources": [
-    {
-      "title": "RFC 8259 section 8.2: Unicode characters (unpaired surrogates)",
-      "url": "https://www.rfc-editor.org/rfc/rfc8259#section-8.2"
-    },
-    {
-      "title": "Unicode Standard Annex #15 glossary: Unpaired Surrogate",
-      "url": "https://www.unicode.org/glossary/#unpaired_surrogate"
-    }
-  ],
-  "tags": [
-    "json",
-    "parsing",
-    "validation",
-    "security",
-    "i18n"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "\"\\ud800\""
-      ],
-      "relation": "no_crash",
-      "note": "their_parse_json(text) may legitimately accept this string, but whatever encodes the result to UTF-8 downstream must handle (reject or substitute) an unpaired surrogate rather than silently corrupting it."
-    }
-  ]
-}