Vulnerability disclosure and reporting channels in open source projects

Between late September and early October, several open source projects disclosed vulnerabilities in different ways. Radicle announced two network protocol flaws before a fix was available, and GitHub Security Lab published Android app vulnerabilities found with an AI agent, an AI tool that carries out several steps on its own, after they were fixed. A collaborator on Exclave and Xray-core's author give different accounts of whether Xray-core told users about a February fix. Google's open source vulnerability reward programme also stopped accepting product vulnerability reports on 1 October.

People using Radicle private repositories, OsmAnd and Wikipedia Android users, and Xray-core users who pin a public CA certificate should check their versions or settings. As of 8 October Radicle had no fixed release, and it advises stopping use of private repositories until one is out.

Radicle, a peer-to-peer code collaboration tool built on Git, announced two vulnerabilities on 23 September. Data between nodes is sent in plain text, so anyone on the network path can read it. Authentication at the start of a connection is also flawed, letting an attacker impersonate a node on the allow-list to fetch a private repository, but the attacker first needs to know an allow-listed node ID, and the list is not public.

The announcement says the realistic threat is anyone on the path between two nodes, and all released versions are affected. Repository contents are signed, so tampering on the path is detected, and the main risk is information leakage. Public repositories are less affected.

As of 8 October there was no fixed release, and the announcement says the fix replaces the networking layer with the open source iroh and will not interoperate with older versions. It advises stopping use of private repositories until then, treating any private repository already sent over the network as leaked, and rotating unencrypted credentials, keys and tokens in them. It also says that routing traffic through Tor, I2P or a VPN does not prevent impersonation.

GitHub Security Lab wrote on 28 September that its team used its own Taskflow Agent to have an AI model work step by step through the entry points of Android apps, meaning functions other apps or links can trigger. By the time of writing, the team had reported 24 vulnerabilities. The author wrote that AI often reports issues that are very hard to trigger in practice and misjudges severity, so every finding needs review by a researcher who knows mobile apps. According to the repository's licence label on GitHub, Taskflow Agent is MIT-licensed, and running it requires a GitHub Copilot licence.

As of 8 October, five Android advisories on GitHub Security Lab's advisories page matched the article, all published on 1 October. One lets a malicious app with no permissions obtain OsmAnd's real-time location, and another lets an attacker steal the Wikipedia app's login cookie through a link. According to the advisories, Wikipedia confirmed fixes in April and OsmAnd in June, and we could not find which versions contain them.

Xray-core is the core component used by proxy clients such as v2rayN. An advisory published on 10 July says that when pinnedPeerCertSha256 is used to pin, meaning accept only a specified certificate, a public CA certificate, parts of the Hysteria and gRPC connection paths do not check the server name. Other certificates issued by the same CA, the organisation that issues website certificates, can then pass verification, exposing connections to man-in-the-middle attacks. The advisory rates the severity as low, affected versions are v26.1.13 and later, and the fix is in v26.7.11.

A collaborator on Exclave, another proxy tool, wrote on that project's discussion board on 29 September that he privately reported a verification bypass in the same option on 6 February. In his account, Xray-core fixed it the same day under a commit described as simplifying code and released a new version without telling users. He also wrote that on 3 July he found the fix incomplete and switched to GitHub's vulnerability reporting, which became the July advisory, and in a v2rayN thread he wrote that in February he had notified another Xray-core developer.

As of 8 October Xray-core had not replied to the Exclave post. When a third-party user raised similar concerns in a v2rayN discussion in late July and early August, Xray-core's author wrote that February's change fixed a different problem. The author wrote that the July flaw only affects pinning a public CA with Hysteria or gRPC. The author also wrote that the February release notes said "重要修复，请及时升级" (important fixes, please upgrade promptly), and that the other developer who submitted the February change had not told him it contained a fix.

Google's open source vulnerability reward programme rules say it stopped accepting product vulnerability reports on 1 October. As of 8 October supply chain issues, such as leaked signing keys, are still accepted, and the rules say an update will come in the first quarter of 2027. According to The Hacker News, Google's post on X gave the reason as a significant rise in automated submissions, most of them invalid. The report adds that the post did not say whether the submissions were AI-generated.

Perspective

In a typical coordinated disclosure, the finder reports privately, the project fixes the flaw and then publishes an advisory, requesting a CVE ID, a public identifier for the vulnerability, where needed. GitHub repositories can enable private vulnerability reporting, and where it is off, GitHub's documentation suggests following the repository's security policy or opening an issue to ask for a contact. GitHub Security Lab's five advisories were published after fixes and all have CVE IDs. Xray-core's advisory was published 15 minutes after the fixing commit and has no CVE ID.

Radicle chose to disclose before the fix, and its announcement says users can act today, while no later fix can undo exposure that has already happened. We infer that the cost of disclosing early is that attackers learn about the flaw too.

The Xray-core dispute is about whether a fix should be clearly flagged to users. Xray-core's author argues that few setups are affected and the release notes already urged upgrading, writing "只是这种东西需要大张旗鼓通报吗" (does something like this really need a big announcement). The Exclave collaborator wrote that Xray-core released a new version without mentioning the flaw, leaving users "蒙在鼓里" (in the dark). The two accounts differ on what the February change fixed, and we cannot tell from the public record.

GitHub Security Lab wrote that AI-powered security research is currently one of the best ways to secure open source projects. Google's March blog post said AI-generated reports had surged, some containing incorrect information. According to The Hacker News, Google's post when it stopped taking reports in October gave automated submissions as the reason and did not say whether they were AI-generated.

Mainland China, Japan and Taiwan handle disclosure differently. In mainland China, the Regulations on the Management of Network Product Security Vulnerabilities, in force since September 2021, require network product providers to report a vulnerability to the Ministry of Industry and Information Technology's platform within two days of discovering or learning of it. Anyone publishing vulnerability information may not do so before the provider offers a fix.

Those who think early publication is necessary must consult the provider and report to the Ministry of Industry and Information Technology and the Ministry of Public Security, which assess the case and publish. Undisclosed vulnerability information may not be given to overseas organisations or individuals other than the product provider. The regulations do not say whether open source maintainers count as providers.

Japan's Information Security Early Warning Partnership routes reports through the Information-technology Promotion Agency (IPA), which receives them, and JPCERT/CC, the national computer emergency response coordination centre, which coordinates with developers, aiming to publish 45 days after the first attempt to contact the developer. Its guidelines treat open source software as a product even when the developer can only be identified as a community, and the 2026 edition published on 1 October adds notifying the Cabinet Office about vulnerabilities confirmed or suspected to be exploited, or serious enough to have wide impact if exploited.

In Taiwan, TWCERT/CC, the Taiwan Computer Emergency Response Team/Coordination Center, has been a CVE Numbering Authority, an organisation authorised to assign CVE IDs, since 2018. Its disclosure policy says it publishes a report's basic details within 90 calendar days of confirming the report is complete, though it may delay publication or limit the detail. The policy defines vendors as manufacturers of affected products and does not mention open source projects.

Following GitHub's documentation, open source maintainers can enable private vulnerability reporting on GitHub or add a security policy with contact details to their repository.

People using Radicle private repositories can follow the announcement and stop serving them, which does not delete local copies, and rotate unencrypted credentials in any repository already sent. Data already synced cannot be recalled. We infer that updating OsmAnd or the Wikipedia Android app to the latest version should include the fixes, though we could not find which version. The July advisory only covers setups pinning a public CA certificate over Hysteria or gRPC, and since the two sides disagree about February's fix, we infer that anyone using pinning can check that their tool's built-in Xray-core is v26.7.11 or later.