There are more inconsistencies.

It states that affected systems need to have the "GlobalProtect gateway feature" enabled. The actual advisory states "firewalls configured with GlobalProtect gateway or GlobalProtect portal (or both)".
The stated patched versions are not including all of the advisory.
And I didn't even look into all those claims about which groups exploited this CVE.

This just blows my mind again. GitHub also made similar mistakes in their recent Copilot announcement [3].

I think it's just important to understand that it is not enough to just add a pop up saying "make sure to double check all AI responses" if Google cannot even be arsed to do that for the marketing material they release.
Everyone will just rely on the response.

As a side note: Wow, the resolution of the AI response screenshot is utter crap and someone even left their mouse pointer just hovered over the text. If this was in a pentest report I would read quality assurance for, I'd tell the author to go back and fix that!

[3] https://infosec.exchange/@faker/113680171927908019
#secgemini

faker (@[email protected])

Attached: 1 image Another case of "AI demo posted on vendor website is just plain wrong". This is currently on the GitHub Copilot site (https://github.com/features/copilot). The prompt is "how do i copy all the files bigger than 128k" and it answers: "find . -size +128k" This doesn't copy anything. It just "finds" it. It arbitrarily restricts to the current folder and doesn't include ALL files. Arguably the copy part is the most complicated part that would follow this find command. Are you doing "| xargs" or the weird "-exec cp {} dest \;" way that I always get wrong on the first try? Additionally, if the user specifies already "all files" then "-type f" should certainly be used too. Although I can't think of a filetype right now that is >128k and not a file, if you use this as an example for something else, you might have a bad time. Does nobody proof read these examples?

Infosec Exchange

Another day, another AI is announced. This time its a cybersecurity AI by Google: Sec-Gemini v1 [1]. As always, lets look at the response of it that was included on their announcement post. Surely the response was vetted and confirmed by multiple people, right?

The prompt asks about CVE-2024-3400, and at first glance this appears ok.

But in the affected systems section it states:

> Also Hitachi Energy RTU500 firmware and Siemens Ruggedcom APE1808 firmware.

I cannot find any reference that this Hitachi device is vulnerable to that CVE. Hitachi has a nice interface to list all vulnerabilities of their devices [1], this CVE is not part of it.
In the Mitigation section any mention of Hitachi is also missing. Almost as if this device is not vulnerable.

[1] https://security.googleblog.com/2025/04/google-launches-sec-gemini-v1-new.html
[2] https://www.hitachienergy.com/products-and-solutions/cybersecurity/alerts-and-notifications?filterable-1529399537-productTags=taxonomy-cybersecurity%3Aproducts%2Frtu500

#secgemini

Google announces Sec-Gemini v1, a new experimental cybersecurity model

Posted by Elie Burzstein and Marianna Tishchenko, Sec-Gemini team Today, we’re announcing Sec-Gemini v1, a new experimental AI model focused...

Google Online Security Blog
Google Lansează Sec-Gemini v1: Model experimental de securitate cibernetică – TECHNEWSRO

🎉 #Google just birthed another #AI superhero, #SecGemini v1, to fight the evildoers of the #cyber realm! 🤖 One more experimental model to ensure we're all safely surfing, while villains plot their single, sinister loophole. Definitely not another shiny toy for data miners to play with! 🌐🔒
https://security.googleblog.com/2025/04/google-launches-sec-gemini-v1-new.html #cybersecurity #technology #safety #innovation #HackerNews #ngated
Google announces Sec-Gemini v1, a new experimental cybersecurity model

Posted by Elie Burzstein and Marianna Tishchenko, Sec-Gemini team Today, we’re announcing Sec-Gemini v1, a new experimental AI model focused...

Google Online Security Blog