A taxonomy of systems that bend, break, and behave oddly.
Every investigation we publish lives somewhere in this catalogue. Browse the domains, protocols, and platforms that have proven most willing to misbehave under the right kind of scrutiny.
Twelve domains, each with its own kind of trouble.
Topics are grouped by the layer of the stack they live in. A note can belong to more than one cluster, but the index puts each investigation under the system it most directly disturbs.
Carrier-grade NAT & residential proxy abuse
How middlebox translation quietly rewrites the topology of the public internet, and the small handful of behaviours that consistently escape it.
Consumer routers, repurposed
What happens when firmware support ends but the device keeps serving a household. Field reports from twelve different SOHO platforms across four chipset families.
DNS, when it lies
Cache poisoning, resolver politics, the quiet failure modes of DOH and DOT, and the small subset of behaviours that even a hardened stub resolver can't defend against.
Container runtimes at the edge
Notes on seccomp escapes, ambiguous UID mappings, and the failure of a popular runtime under unusual cgroup v2 hierarchies. Reproducible in 40 lines of Dockerfile.
Smart bulbs, dumb protocols
An ongoing survey of Zigbee and WiFi-connected lighting that prefers to phone home. A handful of vendors have been quietly helpful; the rest have been less so.
Group chat that forgets
Server-side retention policies, disappearing message clients, and the uncomfortable distance between a platform's privacy promises and its backup infrastructure.
Load balancers, misheard
A study of how six popular reverse proxies disagree on what a valid HTTP/2 preface looks like, and the small class of malformed requests that reach the upstream on exactly one of them.
Display firmware, updated never
External monitors and TVs that ship with USB-C, Ethernet, or Bluetooth stacks the manufacturer has no intention of patching. Mostly harmless, occasionally less so.
TLS, between the lines
What gets renegotiated, replayed, or quietly downgraded when a client and server disagree on which extension set is normative. Includes a small reproducible downgrade we found in the wild.
How a system earns a place in the index.
Every cluster on this page began the same way: somebody noticed a behaviour that didn't match the documentation. The four stages below describe how a stray observation becomes a filed note.
Notice the seam
Start with a moment of friction: a log line that doesn't add up, a latency spike that survives a clean cache, a UI affordance that suggests a feature the docs don't mention.
Isolate the layer
Reduce the system until the surprising behaviour still reproduces. Knowing which layer owns a quirk is half the work; the other half is writing that down so it can be checked.
Document the boundary
Write the note from the outside in: what you'd expect, what you saw, the smallest possible reproduction, and the smallest set of conditions under which the surprise disappears.
File it publicly
Publish the note under a topic, cross-link it to neighbouring quirks, and — where the vendor is interested — open a quiet conversation about the boundaries we found.
Three things the index is for, and one thing it isn't.
The Misfortunates isn't a vulnerability database and it isn't a vendor review site. It sits closer to a working notebook — useful to the people who would have written the same notes themselves, given the time.
Reproduction over rhetoric
A note earns its place by being checkable. Where we can, we ship the smallest configuration that still demonstrates the behaviour, and we tell you plainly when we can't.
Boundaries, not blame
We're interested in the edges of a system, not in catching it out. Most of the notes here were filed by people who'd happily use the same software the next day.