OpenPorte 1.30.3 is out, and it is a security release. If your WordPress site runs OpenPorte together with Contact Form 7 or HTML Forms, please update now.
What was wrong
To place the OpenPorte widget inside Contact Form 7 and HTML Forms forms, the plugin expanded every shortcode in the form just before it was displayed. The trouble is what that form contains by then: the values a visitor typed into its fields, or put in the page’s URL. A visitor could therefore make your site run any shortcode registered on it, without logging in.
What that allows depends on your site. WordPress’s own shortcodes can list media attached to private or draft posts. Shortcodes from other plugins can carry their own flaws, which normally need a logged-in author to reach and here became reachable by anyone. Neither the integration settings nor the CAPTCHA itself stopped it.
The flaw is old: OpenPorte inherited it from ALTCHA Spam Protection, where it arrived in 1.6.0 (Contact Form 7) and 1.7.0 (HTML Forms). It is tracked as GHSA-hvr5-q69x-jp62 and rated high (CVSS 7.3).
Still on ALTCHA Spam Protection? Every release up to its last GPL version, 1.26.3, is affected, and that plugin is no longer maintained, so no fix will come there. Switch to OpenPorte 1.30.3: it imports your ALTCHA Spam Protection 1.x settings and keeps its free, self-hosted features, including the [altcha] shortcode. Only the paid altcha.org SaaS mode was not carried over; sites that used it fall back to self-hosted challenges.
What changed
OpenPorte now renders only its own [openporte] and [altcha] tags, and only from the form as you wrote it, before any visitor input is added. Visitor input is never run as a shortcode any more.
One side effect: shortcodes from other plugins placed inside a Contact Form 7 or HTML Forms form may stop rendering. Neither form plugin renders shortcodes in its forms on its own. If yours still render after the update, another plugin is expanding them, and it may be open to the same kind of flaw: check with its author.
I chose not to offer a switch to bring the old behaviour back: it would re-open the hole on every site that flips it, and nothing in the admin would remind anyone that it is on. If one of your forms relied on such a shortcode, ask in the support forum and we will find a safe way together.
Contact Form 7 users can now write the widget language as [openporte language:de_DE]. The old [openporte language="de_DE"] keeps working.
Thanks
Thanks to Erik Debye, who reported the issue privately through GitHub. That gave us the time to fix it properly, test it against real Contact Form 7 and HTML Forms installs, and release the fix together with the advisory.
The analysis of the vulnerability, the fix and its release were AI-assisted: I worked through them with Claude (Anthropic’s AI assistant), and reviewed, tested and signed off every change myself.
Links
- Release notes: https://github.com/openporte/openporte/releases/tag/v1.30.3
- Security advisory: https://github.com/openporte/openporte/security/advisories/GHSA-hvr5-q69x-jp62
- Plugin on WordPress.org: https://wordpress.org/plugins/openporte/
This post was written with the assistance of Claude, an AI assistant by Anthropic.
Made with 💘 in the Ruhr area, Germany.



