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.

OpenPorte 1.30.0 is out on GitHub and WordPress.org. This is a security release, so please update: it fixes two published security advisories, GHSA-vwx9-x8p5-xvmp and GHSA-8g7w-538v-w54x, both rated medium, plus three smaller hardening fixes.

It all started with the release of Qwen3.8, an open-weight large language model, and I wanted to test its actual capabilities on my codebase. So I gave it a task to perform a security review of the code (at the time v1.29.1). It was able to detect minor security or robustness issues which Opus 4.8 missed when it reviewed the release v1.27.1. I decided to include them in our current release cycle which included some new features.

And before shipping, I had the development branch reviewed again for security, this time with the help of two other AI code reviewers, Anthropic Claude Opus-5.5 and OpenAI Codex GPT-6-Astra. They found several ways a bot could skip the proof-of-work, or use less resources for it, on some forms and setups. Most of them were inherited from ALTCHA Spam Protection v1, some from its very first release. None of them exposed data, credentials or admin access, and passwords were always checked. What a bot could skip was the cost the proof-of-work provided by ALTCHA is there to add.

The two security advisories

Advisory	Severity	Affected	Fixed in
GHSA-vwx9-x8p5-xvmp: Solved CAPTCHA challenges accepted after their expiry	Medium	OpenPorte ≤ 1.29.1, ALTCHA Spam Protection ≤ 1.26.3	OpenPorte 1.30.0
GHSA-8g7w-538v-w54x: Login CAPTCHA checked only after the password	Medium	OpenPorte ≤ 1.29.1, ALTCHA Spam Protection ≤ 1.26.3	OpenPorte 1.30.0

• Expired challenges (GHSA-vwx9-x8p5-xvmp): a solved challenge could be altered so that its expiry was ignored, and reused long after it should have been refused. The Replay limit from 1.29.0 still capped the reuse, but expiry is meant to be the first line of defence. In Custom API Mode, a backend issuing challenges in an outdated format had the same problem (more on that below).
• Login order (GHSA-8g7w-538v-w54x): on the login forms, the challenge was checked only after WordPress had compared the password. Guessing passwords cost nothing, and the error message even told a correct guess apart from a wrong one. Now the challenge comes first: without it, every attempt gets the same error.

CVE IDs have been requested and will be added to the advisories when they are assigned.

Still running ALTCHA Spam Protection 1.x? Both flaws are in it too, and it is no longer maintained, so there will be no fix there. OpenPorte imports your 1.x settings and keeps the free, self-hosted features backward compatible, the altcha shortcode included; only the paid altcha.org SaaS mode and its spam filter were not carried over. If you rely on those, the official ALTCHA plugin, now a new generation that is no longer GPL-licensed, offers them: see altcha.org.

The other fixes

On sites running WooCommerce, a forged form field could skip the WordPress login and password-reset checks. With the CoBlocks integration switched off, OpenPorte still overrode CoBlocks’ own reCAPTCHA (that one was discovered by Qwen3.8-27B). And in Custom API Mode, the site kept issuing challenges of its own, which let bots go around the backend’s rules. The full list is in issue #126.

If you use Custom API Mode, open the OpenPorte settings page once after updating. The backend check now also warns when your backend issues challenges in an outdated format, the case behind CVE-2025-68113 and the second cause of GHSA-vwx9-x8p5-xvmp. Purge your page caches too.

Release v1.30.0 not only contains fixes, but two new settings/features:

• OpenPorte now supports an Ajax transport next to the existing REST API. A new setting allows for self-hosted mode switching the transport serving challenges through admin-ajax.php instead of the REST API. The intended use case is for sites whose security plugin blocks the REST API for visitors. OpenPorte still defaults to using the REST API transport, which we recommend using. Thanks to factor11 for the report and the workaround.
• And “Keep settings when the plugin is deleted” lets you remove and reinstall OpenPorte without losing its configuration. It is off by default, so the plugin’s settings are removed when uninstalling it.

Developers: the openporte_replay_limit filter now also receives the form the token was submitted on, so you can be stricter on replay limit for a login page than on comments. Existing callbacks keep working unchanged.

If you allowed automatic updates from WordPress.org, you most likely already have 1.30.0. Your settings are kept.

Known issue: LiteSpeed Cache

Since the release, a user reported that they could not log in on a site running LiteSpeed Cache. With its default settings, LiteSpeed Cache stores REST API responses for seven days and ignores the “do not cache” headers OpenPorte sends. So every visitor gets the same challenge: logins and protected forms fail after five uses (the Replay limit) and for everyone once that challenge expires. This is not new in 1.30.0: it goes back to the first ALTCHA Spam Protection release, and the Replay limit added in 1.29.0 only makes it show sooner. The fix is ready and will ship in 1.30.1. Until then, if you use LiteSpeed Cache, pick one of these workarounds:

1. In Settings → OpenPorte, set Self-hosted transport to Ajax, or
2. in LiteSpeed Cache → Cache → Excludes → Do Not Cache URIs, add /wp-json/openporte/.

Then run LiteSpeed Cache → Purge All once: the stale challenge stays cached until it is purged. Already locked out? Purge the cache from your hosting panel or with WP-CLI (wp litespeed-purge all); the next challenge is fresh, so you can log in and apply a workaround. Thanks to Nico for the report and the quick feedback.