ICEBlock handled my vulnerability report in the worst possible way

Quality of the vulnerability report

• Many commenters say the “report” is extremely low quality: essentially an nmap scan, a version string, and a link to a CVE, with no verification that the issue is exploitable in this deployment.
• Several argue this is indistinguishable from the flood of automated “beg bounty” emails and scanner noise that large orgs routinely ignore.
• Others counter that even a weak report should still be handled professionally by the app developer.

Is Apache actually vulnerable?

• Multiple people note that version strings on Linux distros are misleading: RHEL/Debian/Ubuntu often backport security fixes while keeping the old version number, so “Apache 2.4.57” doesn’t prove unpatched CVEs.
• Some highlight that the cited CVE is highly situational (requires specific reverse-proxy / header-manipulation conditions) and there’s no evidence those conditions exist for ICEBlock.
• A minority argue that outdated apparent versions are still a strong “brown M&M” signal of broader security rot.

Disclosure process and timelines

• Several think giving 90 minutes before publishing the first critical post, and a one-week ultimatum before the second, is unreasonable and not “responsible disclosure.”
• Others emphasize the distinction between “responsible” and “coordinated” disclosure and push back on vendor-centric norms, but still see the execution here as more “gotcha” than collaboration.

Tone, criticism, and blocking

• Many criticize the reporter’s tone: leading with a harsh “activism theater” takedown, interleaving moral critique with a vague security warning, and generally coming off as hostile.
• Others argue criticism of the app’s concept and implementation is substantively fair, even if strategically unhelpful for getting fixes.
• Some see the developer’s blocking behavior (especially toward security reports) as immature and dangerous; others defend blocking as self‑protection amid harassment.

ICEBlock’s purpose and threat model

• One camp views the app as harmful “activism/security theater” and potentially an unintentional honeypot: closed source, hosted on a US VPS, vulnerable to subpoenas and false reports.
• Another camp argues that even a limited app can be impactful, pointing to strong government backlash as evidence it’s more than “theater.”
• Several note that, given the adversary (federal agencies), merely patching CVEs is far from sufficient; the entire architecture and data-collection model are suspect.

Broader context: vuln-report fatigue

• Commenters repeatedly mention being inundated with bogus or low-effort vulnerability emails (automated scans, SPF nitpicks, irrelevant CVEs) which makes it harder for genuine reports to be heard.
• Some conclude that in this incident “no one looks good”: a fragile, high‑risk app run by an underqualified dev, and a critic whose disclosure approach and technical rigor are both questioned.