On Tue, Jul 07, 2026 at 01:15:04PM -0700, Joe Stringer wrote: I suspect we may have been the initial target for this activity; we received a test email to security () cilium io prior to this email. We also got one just prior to the 4 reports on July 4. I didn't let it through (as a moderator), but it was: Subject: [Test] 2026-07-04 From: xylove21 <xylove21 () proton me> To: oss-security () lists openwall com Date: Sat, 04 Jul 2026 10:12:46 +0800

Test 2026-07-04. Target: oss-security () lists openwall com. No disclosure. Looks like just the way the tool works. I don't know what the purpose of this test was, given it was sent from a non-existent address and further messages were sent regardless of it not being accepted. Maybe the tool was misconfigured.

On Tue, Jul 07, 2026 at 01:15:04PM -0700, Joe Stringer wrote: The feature discussed in the disclosure is an alpha feature that we've been developing this cycle. We identified and fixed the reported issue as part of development activities, so it will not be part of a stable release. The report from xylove21 accurately identified the commit and PR that introduced the bug, as well as the commit that fixed the bug and corresponding PR.

If you asked a model to read git logs to identify changes with security impact, it would probably point to the fix commit referenced in the original message. The combination of "fix" and "network policy" in a commit title is likely sufficient signal. Evidently the claw was also directed to identify which commit may have introduced the issue. I would guess the motivation was to identify known issues which may not have had a public disclosure, and attempt to file a CVE for the issue to claim some credit. Given these versions are not recommended for production and the feature is alpha, we do not see a motivation to file a CVE. Oh, so in your case it was search for recently fixed issues. I wonder if that's also the case for the 4 other reports against other projects. I could not quickly confirm this now.

Alexander

Hello Feroz,

xylove21's AI sent us 4 other claimed vulnerability reports to oss-security, but not actually this one you're replying to (and I just checked the logs, found no trace of it - not even spam-filtered).

Given the confusion about embargoes vs. publication and a lot of other aspects like this, I doubt the vulnerabilities are for real. It feels like a less capable model from last year or older, not state of the art.

On Tue, Jul 07, 2026 at 09:07:11PM +0530, Feroz Salam wrote: As noted in your report, the issue you have reported only affects development snapshots of Cilium, and no released stable versions. We do not expect these development snapshots to be used in production environments, and do not see the benefit of CVE issuance in this case. Have you looked into the reported issue and determined whether it's real or not? I ask so that we have extra input on how to treat other reports by xylove21. From: xylove21 <xuy0515 () gmail com> Unlike the xylove21 () proton me address these reports were sent from, the above Gmail address actually exists, and we got a response from it (probably also written by AI) on another issue. - 2026-06-29 19:56 +08:00 — Filing publicly via oss-security (escalation after 9 days of GHSA Triage silence). - 90-day public disclosure timeline: public release 2026-09-22 (or upon upstream fix in v1.20.0 stable, whichever comes first). If an AI is so poor it "thinks" there's distinction between "Filing publicly" and "public disclosure", it feels unlikely its "reasoning" about the claimed vulnerabilities is sound.

Alexander

cilium-cli is the command line interface to install, manage, and troubleshoot Kubernetes clusters running Cilium. Prior to version 0.13.2,cilium-cli, when used to configure cluster mesh functionality, can remove the enforcement of user permissions on the etcd store used to mirror local cluster information to remote clusters. Users who have set up cluster meshes using the Cilium Helm chart are not affected by this issue.

Due to an incorrect mount point specification, the settings specified by the initContainer that configures etcd users and their permissions are overwritten when using cilium-cli to configure a cluster mesh. An attacker who has already gained access to a valid key and certificate for an etcd cluster compromised in this manner could then modify state in that etcd cluster.

This issue is patched in cilium-cli 0.13.2. As a workaround, one may use Cilium's Helm charts to create their cluster.