strongSwan

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays on the Tier 2 OSS-Fuzz row for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. Memory-safety work can carry a 2× or 3× multiplier. Sanctions and territory exclusions apply, and one-liner fixes for non-exploitable crashes are not rewarded. CVE history 9 Last 12 months 46 Lifetime Memory safety 35 % Auth bypass 25 % Denial of service 25 % Parsing/validation 10 % Latest advisories Loading the feed Overview strongSwan is the dominant open-source IKEv2 implementation and the IPsec stack of choice on Linux: the VPN engine inside a great many enterprise gateways, cloud site-to-site tunnels, Android's built-in IKEv2 client, OpenWrt and pfSense/OPNsense, telco and 5G core interconnect, and industrial remote access. IPsec is what enterprises reach for when compliance demands a standards-based tunnel, which puts strongSwan on the internet edge of exactly the estates that cannot be patched quickly. CVE-2023-41913 is the reference point: a stack overflow in Diffie-Hellman public-value handling, inside a daemon whose whole job is to be internet-facing. The project pays nothing for a report, so sorona.xyz pays you directly on a qualified, reproduced finding. In scope Reports go to the strongSwan security address, which also serves as the project's OSS-Fuzz contact, and the object is the upstream strongSwan tree rather than a vendor's appliance fork or another IPsec implementation The charon daemon in full: the IKEv1 and IKEv2 message parsers reachable pre-authentication on UDP/500 and UDP/4500, and the state machine behind them The authentication plugin family end to end, EAP-TLS, EAP-TTLS and EAP-MSCHAPv2 included, together with the identity-matching logic that turns an exchange into an authentication decision Credential and PKI handling in the pki tool and the credential plugins: X.509 chain building, CRL and OCSP processing, and the RSA and ECDSA verification paths The vici and swanctl control interface and the legacy stroke socket The kernel interface plugins, kernel-netlink above all, and XFRM policy and SA installation, where a policy confusion becomes a traffic-selector bypass Out of scope Libreswan and other IPsec implementations, which are separate projects with no OSS-Fuzz integration and no pathway Weak proposals or pre-shared keys the operator chose, which is configuration rather than a code defect Kernel XFRM and IPsec bugs, which belong to the Linux kernel scope row rather than to strongSwan Vendor firmware forks shipped inside appliances rather than the upstream repository One-line fixes for non-exploitable crashes, which the Patch Rewards rules exclude Most-valued findings Pre-authentication memory corruption in the charon IKE parsers on UDP/500 or UDP/4500. This is the top class here at 35%, the shape CVE-2023-41913 took in Diffie-Hellman public-value handling, and the one that turns an internet-facing gateway into remote code execution An authentication bypass through the EAP plugins or the identity-matching logic, the shape the 2021 EAP authentication bypasses took, which lets an unauthenticated peer establish a tunnel into the protected network Certificate or chain validation flaws in the credential plugins that make a bad certificate verify, since the whole IKEv2 trust model rests on that check Traffic-selector or XFRM policy confusion in the kernel-netlink plugin, where installed policy sends plaintext where the operator believed there was a tunnel, or accepts traffic it should have dropped A remotely triggerable crash in the pre-auth parser path with a real algorithmic cause, on a daemon whose availability is the site-to-site link itself Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report to the strongSwan security address, which is also the project's OSS-Fuzz contact; if it cannot be reproduced it is not eligible Give the maintainers room to ship a fix and publish their advisory before any public writeup Findings in Libreswan or another IPsec implementation belong with that project. Neither is OSS-Fuzz integrated and neither has a pathway here The Google patch money is a separate pathway: you land the fix upstream yourself and keep it merged, without reverts, for one month strongSwan sits on the Tier 2 OSS-Fuzz row, so the patch ceiling is $5,000 rather than the $15,000 Tier 1 figure Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the strongSwan maintainers through [email protected] , which runs the project's own embargo process. Fixes land in a numbered release with a published advisory and researcher credit, so hold the detail until that release is out. Nothing in the Patch Rewards rules restricts who may help you prepare or route the report. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability