ASA2 1.34.0 is now available. It closes three security issues, one of them reachable by any logged-in Contributor. Two new checks come with it: a connection test for your Amazon Creators API credentials, and a PHP version report covering cron and WP-CLI.

ASA2 1.34.0 Closes Three Security Issues

All three carry the reference asa2-103 in the changelog and are technically unrelated to each other.

Broken Access Control on the Dashboard

The ASA2 dashboard is open to every user with the edit_posts capability. That part is deliberate, because editors need the page to reach the Product Picker. The problem sat one layer below: the page did not restrict which ASA2 admin controller an incoming request was allowed to target.

A logged-in Contributor could therefore dispatch actions belonging to the Service, Self-Test, Patches, Templates, Collections, Translations, Options and Migration Wizard pages. The most damaging of those is storing custom CSS, which ASA2 then prints on every page of the site.

In 1.34.0 the dashboard dispatches its own controller and the Product Picker, nothing else. Every ASA2 admin controller now enforces its own capability independently of the menu page a request arrived through. If you have Contributor or Author accounts on your site, this is the fix to update for.

Missing Nonce Checks on the Self-Test and Patches Pages

The Self-Test ran tests and applied fixes, and the patches page executed database patches, without verifying a nonce first. An image tag on a third-party site was enough to trigger one of those actions in the background of a logged-in administrator. Both pages now verify a nonce before they do anything.

Reflected XSS in the Product Picker

The Product Picker uses a uid URL parameter to keep several instances on the same page apart. That value was written into the markup unfiltered. ASA2 now accepts only letters and digits for it and escapes it everywhere it is printed. Exploiting it required a logged-in user to open a crafted link. That puts it in the same class as the admin page XSS fixed in 1.33.1.

The Amazon Creators API Setup Page Now Tests the Connection

The Configured Marketplaces table showed a green badge in a column headed Status, and users read that as confirmation that the connection works. It never meant that. It recorded whether the “Enable Creators API” checkbox was ticked when the credentials were saved. The credentials themselves had never been sent to Amazon.

Support tickets followed a predictable shape: a green badge, no product data, and nothing in the interface pointing at where it broke. The only verification available was indirect, by adding a product and watching whether data loaded.

Two Columns Instead of One

The Status column is now called Enabled, which is what it always measured. A new Connection column sits next to it and shows the result of an actual test:

• Not tested yet (gray): the connection has not been tested since the credentials were saved
• Connected (green): the last test reached Amazon with these credentials
• Failed (red): hover the badge to read the error message Amazon returned

Below the badge sits the date and time of that test, so a green “Connected” from four months ago is recognizable as what it is. A failure message typically names the actual cause: invalid credentials, an Associates account that is not linked, or a rate limit response.

Test Connection sits in the Actions column. It sends one minimal live search request to Amazon using the stored credentials for that marketplace and records what comes back. It works whether or not the marketplace is enabled, so you can verify a new set of credentials before switching them on.

The Connection column reports a real test result. The Enabled column reports your checkbox.

Both columns and the test action are described under testing a marketplace connection. Setting up credentials for a new marketplace is covered in the Creators API setup guide.

Your Host Says PHP 8.3. Your Cron Jobs Disagree.

A WordPress site does not run one PHP version. The web server has one, system cron uses whatever binary the crontab points at, and WP-CLI uses a third. Hosting panels routinely update the web server and leave the command line binary behind. Switching PHP in a control panel usually changes only the web interpreter.

WordPress shows you exactly one of these, under Tools > Site Health > Info > Server. An outdated interpreter anywhere else is invisible in the backend. What you experience instead is scheduled tasks that quietly stop completing, with nothing in the interface pointing at PHP as the cause.

The case that surfaced this: a bundled CSV library uses PHP 8 syntax. Requests routed through a PHP 7 interpreter died with a parse error inside the vendor directory. That library has shipped since ASA2 1.29.0. The customer who reported it had blamed the plugin update rather than the server migration that actually caused it.

What ASA2 Records Now

ASA2 writes down which PHP version it ran under in which environment, and it does so even on the aborted path. A PHP 7.4 cron run therefore leaves a trace that the admin backend, served by a current PHP, can report afterwards. Two places surface it:

• An admin notice titled “Outdated PHP version detected”
• A self-test named “PHP version of all environments”, listing entries in the form PHP 7.4.33 - command line (system cron, WP-CLI)

The wording of the message matters more than the detection. It states that updating the web server alone is not enough, which is the sentence you forward to your host. Support desks otherwise answer with the Site Health value and consider the ticket closed.

Two details keep the check from becoming noise. Entries older than 30 days are dropped, so a retired interpreter stops warning on its own. The self-test’s Fix button clears the recorded versions. That is how you confirm an update took effect: clear the list, let cron run once, then look again.

To check it yourself before contacting anyone, run php -v over SSH. That is the binary cron uses. Compare it against the version under Tools > Site Health > Info > Server, and check the crontab for an absolute path such as /usr/bin/php7.4. The minimum ASA2 requires is documented under PHP requirements.

A Self-Test Dialog You Can Follow

ASA2 ships more than 60 self-tests. The dialog showed the first four of them and named none. A slow test was indistinguishable from a frozen dialog.

The name of the running test now sits in a fixed header. The progress bar and the buttons stay in place. Only the test list scrolls along with the current test, and passed tests collapse to a single line. That leaves failures as the only expanded entries, which is the point of running the tests in the first place.

A run in progress also disables the dialog’s buttons, so a second run cannot be started on top of the first.

Passed tests collapse. Failures stay open.

The self-tests and the rest of the ASA2 dashboard are described on the Plugin Status and self-tests page.

Bug Fixes

One of the four deserves more than a bullet. A product whose stored Amazon data was empty or in an old format could take down an entire page with a PHP fatal error (Typed property ... must not be accessed before initialization). The visible symptom was a white page, which points at everything except one outdated product record. Those products now render without price data instead of stopping the request.

• Fatal error on legacy product data: Covered above. Empty or old-format Amazon data degrades gracefully (asa2-104)
• Parse error on mixed PHP environments: Below PHP 8.1, ASA2 stops loading with an explanation instead of crashing cron and WP-CLI requests inside the bundled CSV library (asa2-102)
• Self-Test progress line: Showed an internal ID rather than the name of the running test
• Dashboard button icon: The icon on “Perform self-tests” was not vertically centered against its label under WordPress 7

Technical Requirements

• WordPress: 6.0 or higher, tested up to 7.1
• PHP: 8.1 or higher, now checked at load time in every environment rather than only declared in the plugin header
• Migration: None. No database changes and no configuration steps are required

Getting Started

1. Update ASA2 through the WordPress dashboard or download version 1.34.0 from your account area
2. Open ASA2 > Setup > Amazon Creators API and run Test Connection for every marketplace you have configured
3. Check the ASA2 dashboard for an “Outdated PHP version detected” notice, or run the “PHP version of all environments” self-test directly
4. Review who holds Contributor and Author accounts on the site, since those were the roles affected by the access control issue

For questions or issues, visit the help page. Full documentation is available at docs.getasa2.com, and the complete history of releases is at the changelog.