Bug Alert

Bug Alert is a service for alerting security and IT professionals of high-impact and 0day vulnerabilities.

Hi, I’m Matthew Sullivan, a security practitioner, and the creator of Bug Alert.

When the Log4j vulnerability was first discovered, it was reported, as most are, on Twitter.
13 hours passed between the time it was disclosed on Twitter to the time LunaSec put out their
widely-shared blog post, and 5 hours passed after that before I saw it up at the top of
Hacker News. By then, precious time for reacting had been completely
lost; it was nearly midnight in my local timezone, and all the people I needed to mobilize were already in bed.

There is no central clearinghouse for notifying security professionals about critical security issues in
widely-used software. The process for issuing security bulletins from organizations like the
CISA are both welcomed and well-intentioned, but by the time a CVE
identifier has been issued, or a bulletin posted, it’s simply too late.

Bug Alert has exactly one goal: rapid notification for serious flaws in widely-used software. This process
is conducted entirely in the open, via our project on GitHub.
Email/phone/SMS notification services are (obviously) not free, but my intent is to keep this effort
funded by community/industry donations, if it is ever needed.

Contributions are highly encouraged! We also need a team of volunteers from around the world who can review
and rapidly merge GitHub pull requests detailing new issues, as they come in. Volunteers need to be kind, level-headed
individuals who are willing to engage a diverse set of people in the security community with unwavering professionalism
and no ego. If that sounds like you, open a GitHub issue letting us know!

What Are Notices & Contributing Your Knowledge

Notices are the lifeblood of this service; they are the text that will explain to the community
what they need to be worrying about, and why. The merging of a new notice kicks off the automated processes
for alerting subscribers by phone, SMS, and email – a potentially expensive operation (telephony
services aren’t cheap!) that gets only one shot. Notices will generally only be merged into this project
for software in widespread use (think hundreds of thousands of installs), and only if there is a
large, immediate, demonstrable risk
to the systems that are running the vulnerable software.

If you want to submit a notice, simply fork this repository, follow the template in
content/notices/202X-MM-DD-slug.md.template to author a new notice, and make a pull request.

0day vulnerabilities will be the most commonly-reported issue for this project, but Bug Alert’s
notices are not exclusive to 0days. For example, when Log4j 2.15.0 was released to address a years-old
issue with prior 2.X.X versions, the security community almost immediately found a vector for denial-of-service
(not worthy of a Bug Alert notice). However, a day later, once the DoS issue had already been patched
by 2.16.0, researchers found that the vector for DoS in 2.15.0 could also be used for remote code execution.
Such a finding would be worthy of a Bug Alert notice, because 2.15.0 was likely to be in widespread use
at the time the new vector for RCE was found.

Notices are required to have several fields, the most important of which are Summary, Category,
and Tags. Always use the template found at content/notices/202X-MM-DD-slug.md.template to craft a
notice, and refer to this README for what acceptable values for summary, category, and tags should be.

Assigning Severity

Severity levels are ‘High’, ‘Very High’, and ‘Critical’. Make a best effort based on the criteria
below, but please be aware that project maintainers may raise or lower your proposed severity based
on their own knowledge, experience, and understanding. A new Bug Alert notice may quite literally
wake someone up out of bed; our goal should be to only do that when it is truly necessary and appropriate.

High Severity

The high severity level is to be used for vulnerabilities that are extremely damaging, but
only in configurations that are found less often in real-world environments, or have other migitating factors.
These issues need attention, but nobody is working overnight or during the weekend to patch systems.

Example: A flaw in Adobe Reader for Windows can be utilized to install malware on a single user’s
system, simply by opening a malicious PDF file.

Very High Severity

The very high severity level is to be used for vulnerabilities that introduce remote code execution,
privilege escalation, information disclosure/leakage, etc, where the impact may be high, but
other mitigating factors are present (necessary insider knowledge required for exploit, chaining
of vulnerabilities is required for successful exploit, etc). These issues need prompt attention
and may require an unexpected evening maintenence window, but you can probably keep your date night

Example: A flaw in Microsoft Active Directory allows any authenticated domain user on the local
network to escalate their role to Domain Administrator.

Critical Severity

The critical severity level is reserved for vulnerabilities that introduce remote code execution,
privilege escalation, information disclosure/leakage, and similar issues which, if exploited,
will lead to massive reputational and financial damage; the types of vulnerabilities that
make national news. These issues need immediate attention, and you’ll be working nights and
weekends until you are certain you’ve got everything patched up.

Example: A flaw in Django, a widely-used Python webapp framework, allows an unauthenticated attacker
to run arbitrary commands on the server via the Internet and retrieve the results of those commands.

None of Those Seem To Fit?

If the issue you want to report doesn’t fit the descriptions above, it may be that the issue
is not of high enough impact to be served by this project. We appreciate that you took the time
to consider reporting the issue to a wider audience, and will encourage you to share your
knowledge on social media such as Twitter or Reddit’s security-focused subreddits.

Types of vulnerabilities generally outside the scope of Bug Alert’s focus are described below.
Use your judgement though, and don’t hestitate to submit a notice if you are confident the wider
security and IT communities need to know immediately about an issue.

For example, while DoS vulnerabilities are generally out of scope, an attack that could
crash-loop an nginx server in one packet would still be worthy of a notice.

Issues generally outside the scope of this project include:

  • Software not in widespread use
  • Denial of service
  • Protocol attacks (e.g. TLS cipher downgrade)
  • Attacks requiring local network access (e.g. Microsoft SMB RCEs)
  • Attacks heavily relying on user interaction (e.g. user must be tricked into downloading an executable)


Summary is the text which will be shared in notifications sent out to all subscribers. It is
the most critical piece of information, and accuracy and clarity is key. For subscribers
who opt to recieve phone calls, the summary will be converted to spoken word through Google’s
Text-to-Speech engine.


Tags should make it easy for someone to browse the bugalert.org site and find previous issues
related to a specific component. Tags are a comma-separated list that should include the name
of the component, the framework or runtime (if applicable), and the severity rating.

For example, a critical issue impacting the popular Java library ‘Jackson Databind’ should
include the tags jackson-databind, Java, and Critical Severity.


Category is used to segment which notices subscribers would like to receive. There are four
options, and notice authors must only pick one:

Software Frameworks, Libraries, and Components

Most commonly used for open-source components.

Examples: Django, Flask, Rails, Angular, Spring Boot.

Operating Systems

For operating systems, in desktop, server, and mobile flavors.

Examples: Windows SMB, Linux Kernel, iMessage, Apple Darwin.

Services & System Applications

For services not written by the operating system vendor, core components,
and language runtimes. This category can also include components primarily
indended for end-users, but that are rarely installed by the average
non-administrative user of a system.

Examples: openssh, Apache HTTP Server, nodejs, nginx, Java Runtime, vim, curl, Python.

End-User Applications

Applications that your average non-technical user uses regularly, often without
updating, unless an automatic updating mechanism is built into the application.

Examples: Firefox, Chrome, Thunderbird, Outlook, Adobe Acrobat Reader, Spotify,
Audacity, VLC, Steam, Microsoft Office.


Pull requests are welcome and encouraged.

Run Locally

Clone this repo and cd into it:
[email protected]:BugAlertDotOrg/bugalert.git && cd bugalert

Clone the bugalert-pelican repo in as well:
[email protected]:BugAlertDotOrg/bugalert-pelican.git

In a Python 3.6+ environment, install all project requirements:
pip install -Ur bugalert-pelican/requirements.txt

After that, you can run a local instance with:
rm -rf output && pelican --autoreload --listen -s bugalert-pelican/pelicanconf.py


View Github