14.3 seems to come from some Red Hat-specific GCC version, which can be reported as "gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)". See these random examples I found by googling:
On the same line it says kernel version 6.12.0-124.45.1.el10_1. Which is RHEL 10. This is the kind of typo that humans make -- the hard to type numbers are accurate because they're cut and pasted, but the "easy" numbers have errors because they're not cut and pasted.
ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!
Hope the 'marketing' had the desired effect. This entire article of pure AI noise was an absolute slog to get through to get to useful information. I have no idea how you view that as positive advertising.
I don't quibble with your wanting to make money, but you also need to invest some resources on fact-checking, proofreading, and editing your work. You can hire technical writers and marketing copy editors on an hourly basis as needed. LLMs aren't good enough yet to produce high-quality output on their own; and the results tend to read similarly, loaded with clichés and identical turns of phrase.
(You're not alone in this, BTW; I don't mean to single you out.)
I would rather people who find this kind of stuff pad their resumes and get coolness points on HN than sell this exploit on the black market. But your priorities may be different and you might prefer they do the latter.
The fact that they have no idea RHEL 14, probably the most well known enterprise distro, is not a thing, and yet they "directly verified on it" casts some doubt on seriousness.
I don't know what to tell you. I'm sure you have them dead to rights on Linux distro knowledge reliability, but the exploit here is real, and the vulnerability researchers they have on staff are also real. Xint is not generally a slop factory.
It's ironic that the one thing LLMs can't do reliably in this space is "write copy for humans" (I don't trust them for that either).
Honestly I feel like a coding agent review would have caught this issue. I guess if you want to vibe-code your branded CVE web site it's not a bad idea to at least mash /review at the end.
Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?
I don’t know if “cool” is the word I’d use, but there isn’t an established “right” way to disclose a vulnerability that you found outside of a contracted security review or other employment/contracting arrangement.
