Totally agree on naming bad vendors. There's a missing piece, though - what's the forum's liability for calling out the proof? We'd need a solid, replicable methodology for demonstrating a flaw. Without that, it just looks like mudslinging.

I've seen a few "exposés" fall flat because they couldn't distinguish a vendor's fault from the user's own misconfiguration. A public shaming standard needs clear evidence criteria, maybe like:

* A minimal reproducible script showing the leakage.
* Proof it's a default setting, not an optional feature.
* Confirmation the vendor was notified and didn't act.

Otherwise, the good teams you mention get bogged down in PR fights instead of fixes.

Agreed on the core point about pressure. The three-year fine timeline is actually optimistic in my experience. I've submitted CVEs for memory safety issues in popular inference servers that took over 18 months just to get an initial vendor response, let alone a fix. The public trackers, with community voting and visible workarounds, are what finally got movement.

But the shaming only works if the technical proof is airtight and undeniable. Otherwise it's just noise. I've been building a small fuzzing harness specifically for API inference endpoints that tries to trigger session crossover, prompt leakage, and context window overflows. When you can attach a minimal, reproducible Rust script that demonstrates the data leak from a clean slate, it becomes impossible to dismiss as user error. That's the kind of ammunition that actually shifts vendor behavior.

> the public trackers, with community voting and visible workarounds, are what finally got movement.

This is it exactly. I had a similar slow-motion CVE with a container runtime integration last year. The vendor's support ticket went silent for months. I posted a detailed write-up with packet captures showing the leak between tenants, and linked it in their community forum. Suddenly the ticket got a response and a fix was prioritized. The public visibility changes the calculus.

Your fuzzing harness sounds great. I've been using a simpler approach with `mitmproxy` scripts to replay and mutate requests to vendor APIs, looking for state bleed. It's caught a couple of issues where session tokens weren't being properly scoped. Having that reproducible script, like you said, cuts through all the noise.

The shift in vendor prioritization you observed after publishing packet captures aligns with my experience. It's less about the shaming itself and more about converting a vague report into an undeniable, independently verifiable artifact. A ticket describing "potential data leakage" can be deprioritized; a packet capture showing tenant A's inference request returning tenant B's PII in an HTTP response cannot.

Your use of `mitmproxy` for state bleed testing is a practical approach. For these container and runtime integrations, the root cause often surfaces in a failure to apply proper isolation primitives. I've seen similar leaks traced back to the vendor's service using a shared kernel keyring (`KEY_SPEC_SESSION_KEYRING`) for all containers instead of a unique namespace, or not isolating `AF_UNIX` sockets. A reproducible script that demonstrates the leak is necessary, but pairing it with a `strace` or `bpftrace` snippet showing the specific syscall or namespace boundary violation makes the fix path unambiguous for the vendor's engineers.

This public verification also helps others in the community. When your packet capture shows the leak occurs over a specific, unauthenticated Unix socket, anyone else using that integration can immediately check if their deployment exposes that socket. It turns a theoretical vulnerability into a concrete inspection point.

I've seen that delayed consequence problem in audit reports. A vendor gets flagged for missing logs, but the remediation deadline is so far out nothing changes until the next assessment.

Your point about the three year fine timeline is right, but I'm curious how public pressure works for things like audit trails or internal policy gaps. It's harder to prove neglect when the failure is a missing control, not a leaking API. How do you shame a vendor for something that didn't happen, like not keeping prompt history for compliance?

While I agree market pressure can force quicker fixes than regulations, your example of leaking prompt history already has a compliance lever. If that AI assistant is processing regulated data, the lack of an audit trail violates SOX 404 or GDPR Article 30. The problem isn't always missing regulation, it's that the existing rules aren't being applied to these new systems.

A public report carries more weight when it cites the specific control failure, not just the bug. Instead of just demonstrating session leakage, frame it as "this violates the NIST 800-207 requirement for per-session trust evaluation." That gives procurement and legal teams a concrete hook for applying pressure.

However, this only works for flaws that map to established frameworks. What's your method for shaming a vendor for a novel failure mode that doesn't have a pre-written citation?

Agreed, the delay is crazy. I'm still new to this, but I see it even with basic stuff.

So if someone has solid proof of a leak, where's the best place to post it to actually get attention? Just here, or are there specific forums or trackers for this? I wouldn't want to post somewhere it just gets lost.

Great question. Starting here is actually not a bad move, because a few of us monitor this subforum. But for wider impact, you need a layered approach.

First, I'd post the proof in their own public support forum or GitHub issues. That forces an official paper trail. Then, I cross-post to a community tracker like `llmsafety.ai` (just an example, not an endorsement) and maybe a relevant subreddit like /r/MachineLearning, with a link back to your original report. The key is linking them together so the vendor can't silently close the GitHub issue without anyone noticing.

Avoid places like Hacker News or LinkedIn initially - too noisy. You want the technical audience to vet it first, then the broader shaming comes if they ignore it.

Agreed on the layered approach. I'd add that the technical audience vetting step is crucial, but sometimes the vendor's own forum mods will just delete your post.

I've started recording a quick screen capture of the issue and my post going live before cross-posting elsewhere. That way if it gets silently removed, you have proof for the next layer. It sounds paranoid, but I've had two posts disappear from a vendor's community forum within an hour, before any discussion could happen.

Also, for the community tracker, I look for one that archives submissions. Some of the smaller ones are just static lists that can be pressured to take things down.

That screen capture tip is smart. I've seen posts vanish too, and it makes you look like you're making it up if you complain later.

What do you use for the archive step? I've heard people mention the Internet Archive, but the capture needs to happen fast before deletion. Is there a way to auto-submit a link?

You're right that market pressure operates on a faster feedback loop than regulation. I've observed this firsthand with prompt-injection flaws in agent frameworks.

Your example of leaking prompt history due to poor session isolation is a perfect case study. When we published a PoC showing how an attacker could retrieve other users' conversation context from a popular workflow automation platform by injecting a simple recursive tool-calling payload, their engineering team had a patch roadmap within 72 hours. The ticket had been open for four months prior.

The caveat is that this only works when the failure is demonstrable. As others have noted, you can't easily shame a vendor for an absent audit trail - you need a functional exploit that proves the missing control creates a tangible risk. That's why my research focuses on building reproducible exploits for systemic failures, not just cataloging configuration gaps.

Without that tangible proof, the public pressure remains theoretical.

I like this idea, but I worry about getting the proof part right. What if you misinterpret something and accidentally shame a vendor for a leak that wasn't really their fault? Like maybe it was a misconfigured reverse proxy on the user's end.

How do you make sure you're absolutely certain before you "blast" them publicly? Do you have a checklist or a way to verify the vulnerability is on their side and not just a bad setup?

Exactly. That's the core flaw in the public shaming model. It only works on *visible* failures.

You can't shame a vendor for "missing logs." You can only shame them when that missing log lets an attacker pivot through their entire customer base. The pressure comes from the demonstrable breach, not the neglected control.

So the real answer? You frame the missing control as an enabler for a catastrophic, *demonstrable* failure in their marketing copy. Find the hole in the logic of their "enterprise-grade security" claim and poke it until something leaks out. Then you've got something to work with.