CVE Hive

Community guidelines

CVE Hive is where security researchers share analysis of real-world attacks and published vulnerabilities: what happened, how it worked, who is affected, and how defenders should respond. Every write-up is reviewed by the CVE Hive team before it is published.

There are two kinds of write-up:

  • 🚨 Attack / incident analysis: a breach, ransomware attack or campaign that has been publicly reported. Link your sources. You can start one from any story on Threat Pulse.
  • 🐞 Vulnerability analysis: one or more published CVEs.

How publishing works

  1. Write: sign in and submit a write-up linked to one or more published CVEs.
  2. Review: a reviewer checks it for accuracy, quality and responsible disclosure.
  3. Decision: it is published, sent back with requested changes, or rejected with a reason.
  4. Published: it appears in the public feed and on your profile, marked as peer-reviewed.

✅ What we publish

  • Analysis of vulnerabilities that already have a published CVE or vendor advisory
  • Root-cause explanations, affected versions and patch analysis
  • Detection guidance: logs, indicators, detection rules
  • Mitigation: patches, workarounds, configuration hardening
  • Clear references and credit to original researchers

❌ What we don't publish

  • Unpatched or undisclosed vulnerabilities (0-days). Report these privately to the vendor, or to CERT-In (incident@cert-in.org.in) in India, and wait for coordinated disclosure.
  • Ready-to-use attack code, weaponised exploits or step-by-step instructions for attacking real systems
  • Real targets, leaked data, credentials or personal information. Never share data stolen in a breach, even if it is "already public".
  • Unverified claims or accusations about who was attacked or who did it. Stick to what credible sources report, and link them.
  • Plagiarised content or AI-generated text presented as original research
  • Marketing, spam or off-topic posts

Writing a good write-up

  • Lead with a short summary a non-expert can follow.
  • Be precise about affected and fixed versions.
  • Explain why the bug happens, not just that it happens.
  • Give defenders something actionable: detection and mitigation.
  • Link the vendor advisory and the NVD entry.

Reviews and appeals

Reviewers may request changes or reject a submission with a note. You can edit and resubmit a write-up after changes are requested. Published write-ups can be removed if a problem is found later.

Questions? Email me@projectcnx.in.

Guidelines · CVE Hive