A new vulnerability was published. Does it affect your website?
Security researchers and software vendors publish reports about weaknesses in widely used software every week. Now and then one makes the news, and a manager asks the obvious question: are we affected? Here is what such a report contains and how to answer that question quickly.
What a vulnerability report is
A vulnerability is a flaw in software that someone could use to go beyond the access they are meant to have: read or change data, take over an account, or run their own code on a server.
A confirmed vulnerability usually gets a CVE identifier in the form CVE-year-number. CVE stands for Common Vulnerabilities and Exposures. The identifier is a reference number, so that everyone discussing the flaw means the same one.
A report usually tells you:
- which product and which versions are affected,
- what an attacker could do,
- under what conditions, for example whether they need to log in first,
- whether a fixed version or a workaround exists.
Many reports also carry a CVSS score from 0 to 10. It describes how severe the flaw is in general, and your own setup decides how much it matters to you. A 9.8 in a feature you have switched off can matter less to you than a 6.5 on your login page.
Four questions that decide whether you act
1. Do we run it?
This sounds simple, and many businesses need a list to answer it. A website depends on a content management system, plugins, a theme, a web server, a database, a programming language and many libraries those pull in. A flaw in a small library can affect you even if its name is new to you. With an up-to-date list of what you run, each report becomes a quick lookup.
2. Which version?
The report names the affected version range. If you already run a version that includes the fix, you are done. If you run an older one, the next questions matter. Be aware that Linux distributions and some vendors add security fixes to older version numbers, which is called backporting. A version number on its own can therefore give an incomplete picture, so check the distribution’s or vendor’s own advisory as well.
3. Is the vulnerable part exposed?
Check whether the affected feature is in use and who can reach it. A flaw in an admin tool that only your office network can reach is a smaller risk than the same flaw on a public page. A flaw that needs a logged-in user matters more if anyone can register an account on your site.
4. Is there a fix, and what does applying it take?
Often the answer is a simple update. When a site has gone a long time between updates and many versions have accumulated, the update can affect other parts as well. Until a fixed version is available, the right move is a temporary workaround: switch the feature off, restrict access to it, or add a filtering rule in front of the site. Occasionally the maintainers have ended work on the affected component, and replacing that module is the lasting fix.
How fast to move
If the answers are “yes, an affected version, publicly reachable”, treat it as urgent, especially when the report says the flaw is already being used in attacks. If the part is unreachable or the fix is already in place, write that down and move on. A short note of what you checked saves time the next time the same product appears in the news.
Make the first question easy
The first step usually takes the most time: finding out what you actually run. Our Security watch service keeps that list for you, matches new public vulnerability reports against it automatically, and sends a plain-language fix plan when something you use is affected.