Jump to content
10 minutes ago, starsmine said:

why in the world you you post the source code for a CVE so script kiddies can copy it?
 

In the scientific word a double verification is require, but what I see comes often from the company themselves. So it seems more like press to sell their updated versions/services about how they fixed something 

 

As more research seems to get you into a ratnest without sources 

Link to post
Share on other sites

58 minutes ago, 12345678 said:

In the scientific word a double verification is require, but what I see comes often from the company themselves. So it seems more like press to sell their updated versions/services about how they fixed something

How often did you have to pay for security fixes to make that a legitimate concern?

 

In many cases security vulnerabilities are found by independent parties, who report it to the developer. The CVE number is assigned by a CVE Numbering Authority. Unless the developer also happens to be a CNA, they do not assign the number themselves. The vulnerability (and more importantly the fix) is most likely verified by multiple parties. Doesn't mean the information on how to do it is commonly made public knowledge, since it would only put more people at risk.

Remember to either quote or @mention others, so they are notified of your reply

Link to post
Share on other sites

It used to be common that people discovering vulnerabilities would publish a proof of concept, but the responsible disclosure system has evolved to keep that behind closed doors so that as mentioned the random Joe doesn't have access to it to start using it to attack systems. These days exploit samples only get published as a last resort if the author of the vulnerable code doesn't act upon it to kinda force it to do something "now that everybody knows how to attack your stuff", or as research write-ups a reasonably long time after things have been fixed and people have had time to patch their systems. 

 

The whole point is to prevent more systems being attacked, not the opposite of guaranteeing they get because everybody knows how. It is tracked and verified, you just don't get to be a part of that unless you're in that industry.

F@H
Desktop: i9-13900K, ASUS Z790-E, 64GB DDR5-6000 CL36, RTX3080, 2TB MP600 Pro XT, 2TB SX8200Pro, 2x16TB Ironwolf RAID0, Corsair HX1200, Antec Vortex 360 AIO, Thermaltake Versa H25 TG, Samsung 4K curved 49" TV, 23" secondary, Mountain Everest Max

Mobile SFF rig: i9-9900K, Noctua NH-L9i, Asrock Z390 Phantom ITX-AC, 32GB, GTX1070, 2x1TB SX8200Pro RAID0, 2x5TB 2.5" HDD RAID0, Athena 500W Flex (Noctua fan), Custom 4.7l 3D printed case

 

Asus Zenbook UM325UA, Ryzen 7 5700u, 16GB, 1TB, OLED

 

GPD Win 2

Link to post
Share on other sites

I think there's a bit of misunderstanding about the purpose and process behind CVEs. Let's try to clear up a few points.

 

1. Verification and Trust

In the "scientific world," as you put it, reproducibility is essential. But in the world of security, publicly sharing every exploit method and source code would be irresponsible. Imagine if every CVE came with a full proof-of-concept exploit. It would arm bad actors with ready-to-use attack vectors. Instead, CVEs aim to inform responsible parties (like security teams) about a risk, while giving vendors time to patch it before the full exploit details are published. Some researchers will release PoCs after a patch is available, but it’s not always necessary.

 

 

2. Where Do CVEs Come From?

You’re right that companies often report their own vulnerabilities. This might seem self-serving ("look how responsible we are for fixing things!"), but it’s actually encouraged by the security community. Internal security teams, bug bounty hunters, and external researchers all contribute to the discovery of these issues. It would be a much bigger problem if companies didn't disclose and patch their own vulnerabilities.

 

 

3. Sources and Reproducibility

While some CVEs have minimal public info, many come with detailed descriptions and, eventually, write-ups from researchers. Websites like Mitre, NVD, and platforms like Exploit-DB document these. Full technical details often follow responsible disclosure timelines, so exploiters can’t take advantage before patches are deployed. If you dig into research blogs, you’ll see many security firms (like Project Zero, Cisco Talos, or even independent researchers) posting post-mortems with step-by-step breakdowns of the vulnerabilities.

 

 

4. Is It Just "Press"?

It might feel like a marketing stunt sometimes, especially when companies publicize that they "discovered and fixed" their own bugs. But that doesn't mean the CVE is fake or invalid. It just means they're controlling the narrative. Would you prefer if they said nothing? Or if they didn't fix the bugs? Security is a never-ending process, and part of it is transparency about vulnerabilities.

 

 

 

TL;DR

CVEs aren’t "bullshits." They’re a necessary part of responsible security disclosure. Full details (like PoCs) aren’t always released to avoid enabling attacks. Verification happens behind the scenes, with vendors, independent researchers, and security firms working together. If you want detailed breakdowns, you can often find them after patches are issued, but expecting "open source exploits" for every CVE is dangerous for everyone.

 

If you’re interested in seeing "real-world" PoCs, look at Exploit-DB or check for write-ups on sites like Medium (cybersecurity blogs) after a CVE has been patched for a while. But keep in mind, those releases are always a balancing act between transparency and security.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×