Dashboard

What Is a CVE? A Plain Guide for App Builders

A CVE is a public ID for a known security flaw. Here is how to read one, what the severity score means, and how to tell if it affects your app.

Cecilia Iona
Cecilia Iona
Senior Editor, AI & Product
4 October 20261 min read

A CVE is a public identifier for a specific, known security flaw in a piece of software, written like CVE-2026-61500. It is a label, not a verdict. It lets everyone talk about the same bug, and says nothing by itself about whether you are affected or how bad it is for you. For app builders, the useful skill is reading the entry and deciding within a few minutes whether it touches your stack.

What the letters mean

CVE stands for Common Vulnerabilities and Exposures. The CVE Program maintains the list, and each entry has an ID in the form CVE, a year, and a number. The year is when the ID was assigned, and the number is just a sequence, so a higher number does not mean a worse bug.

An entry is short. It names the product, describes the flaw, and links to advisories and fixes. Everything else, such as scores and exploit status, is added by other sources.

The four things to read first

  • Affected versions. Does the range include the version you run?

  • Fixed version. What do you upgrade to, and is it available now?

  • Severity score. Usually a CVSS number, covered below.

  • Exploit status. Is anyone attacking it yet?

Take this week's Rejetto HFS flaw as an example. Affected: 3.0.0 through 3.2.0. Fixed: 3.2.1. Exploit status: attacks seen within a day of disclosure. That is enough to decide to act today.

What the severity score means

CVSS is the Common Vulnerability Scoring System, which FIRST maintains. It produces a number from 0 to 10, and the specification maps ranges to a label.

Rating

CVSS score

None

0.0

Low

0.1 to 3.9

Medium

4.0 to 6.9

High

7.0 to 8.9

Critical

9.0 to 10.0

The score describes the flaw in general. It cannot know whether the vulnerable feature is switched on in your setup or reachable from the internet. A critical flaw in a service you never installed is not your problem, and a medium flaw in your public login page might be.

Severity is not the same as risk

Three questions turn a score into a decision.

  1. Do I run this software, in an affected version?

  2. Can an attacker reach the vulnerable part, for example because it faces the internet?

  3. Is it being exploited in the wild?

For the third, CISA keeps the Known Exploited Vulnerabilities catalog, which it describes as the authoritative source of flaws exploited in the wild and which organisations are encouraged to use as an input to prioritising fixes. When a CVE you care about appears there, move it to the top of the list. We covered one such case in the Ray framework entry.

Where app builders run into CVEs

A five-minute triage

  1. Read the affected and fixed versions.

  2. Check the version you actually run, on the machine, not from memory.

  3. Ask whether the vulnerable feature is exposed to the internet.

  4. Look the CVE up in the CISA catalog.

  5. If it applies and is exploited, update now. If it applies and is not, schedule it this week. If it does not apply, write down why.

For the wider picture, see the AI risks guide.

Frequently asked questions

Does every security flaw get a CVE?

No. Many flaws are fixed quietly, and some products never request an ID. A missing CVE does not mean a product is safe.

Is a CVE the same as an exploit?

No. A CVE describes a flaw. An exploit is code or a technique that uses it. Some CVEs have public exploits and many do not.

Does a critical score mean my app was hacked?

No. It means the flaw is serious if the conditions are right. Whether you were hit depends on your version, your exposure and whether an attacker found you.

How do I get told about new CVEs for the tools I use?

Subscribe to release or security notices from each vendor, and watch the CISA catalog for products you run. The habit of keeping up with AI news is a small, regular check, like the one you would run for new CVEs.

How did this land?

About the author

Cecilia Iona
Cecilia Iona

Senior Editor, AI & Product

Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.