Heads up for the Freemius SDK team and other plugin authors submitting updates to the wordpress.org repo.
These are the security review concerns that the automated AI scanner is reporting right now in Freemius SDK 2.13.2, as part of their new supply chain attack prevention process. I realize these may be low level and not of priority concern, but I wanted to share it here and raise awareness for future versions and for other plugin authors.
On the plugin's repo page itself:
Version x.x will be released to sites in about 24 hours. WordPress.org currently delays plugin updates by 24 hours so moderators and security scanners can review changes before they reach users. If this update fixes a security issue that needs to ship sooner, contact plugins @ wordpress dot org.
I've recently updated a few other Freemius-based plugins with that banner, and it went away eventually with no email received, but here's the email I received for the first time yesterday with Freemius SDK issues added:
This is an automated security review of your latest plugin update.
Our automated security scan identified issues in the updated files that we want to bring to your attention. The items listed below may represent serious security vulnerabilities that could expose your users to potential attacks, data exposure, or unauthorized access, and we strongly recommend resolving them prior to publication in the WordPress Plugin Directory.
Please review each issue carefully and address them in your next submission.
Please do not reply to this email. This message is sent automatically and replies are not monitored. If you need to discuss the review, wait for the human reviewer's follow-up or contact the Plugin Review Team through the usual channels.
[... some plugin code stuff ...]
Remote Controlled Update at ... /freemius/includes/class-fs-plugin-updater.php:707
Severity: high (Score: 8.1)
Summary
Freemius API response controls the executable package URL injected into WordPress updates.
Context / Rationale
The cited lines do exist and do assign the remote $new_version->url to $update->package, which is later injected into the WordPress update transient. However, this is unmodified, standard Freemius SDK update code that ships verbatim across thousands of plugins, and fetching a package URL from the licensing/update vendor is the documented, intended purpose of the SDK. No attacker-controlled trust boundary is crossed in this plugin: the path requires compromising or controlling the Freemius API/developer account itself, plus a premium/update-eligible flow and an administrator-initiated or auto-update install. That is the inherent trust relationship of essentially every WordPress update mechanism (including core-to-wordpress.org), not a logical vulnerability or malware-like behavior in this codebase. The finding's own boundary concedes it cannot prove an arbitrary-attacker path. Under the chunk rules (remote fetch alone is insufficient; do not report legitimate disclosed update channels; do not require external compromise), this does not support a security finding.
Vulnerable Code
$update->new_version = $new_version->version;
$update->url = WP_FS__ADDRESS;
$update->package = $new_version->url;
$update->tested = self::get_tested_wp_version( $new_version->tested_up_to_version );
Explanation
The remote actor is the Freemius API service, or anyone who can compromise/control the corresponding Freemius release response. The trigger is the WordPress plugin/theme update check: this class registers pre_set_site_transient_update_plugins and pre_set_site_transient_update_themes filters, fetches a remote $new_version, and builds update metadata from that response.
The controlled source is $new_version->url. The visible gate checks that the remote object exists and that its URL query marks it as premium, but this code does not show package host pinning, a cryptographic signature, or a hash verification before assigning the remote URL to $update->package. That update object is then inserted into WordPress’ update transient, where core upgraders consume package as the ZIP to download and install.
The first concrete security effect is a remote-controlled executable update source for PHP plugin/theme code. Exploitation is conditional: this is not an unauthenticated visitor path, and it does not prove direct RCE without an update being applied; it requires Freemius/developer-account/API control or compromise plus a premium/update-eligible flow, and installation still depends on an administrator action or auto-updates. The issue is therefore a supply-chain authority shift requiring human review rather than a proven arbitrary attacker vulnerability.
Suggested Fix & Remediation
No fix is proposed because the supplied evidence does not support a security finding. The code is standard Freemius SDK update behavior and the package URL originates from the trusted vendor API over the SDK's signed request layer; there is no attacker-controllable input crossing a trust boundary in this chunk. If hardening were desired independent of this audit, one could verify package host pinning and signature/hash validation already present in the broader Freemius download flow, but that requires reviewing code outside this chunk and is not warranted by the evidence shown.
Missing Capability at ... /freemius/includes/managers/class-fs-clone-manager.php:836
Severity: medium (Score: 5.5)
Summary
Clone-resolution AJAX action relies on a nonce but does not check user capability before mutating Freemius install state.
Context / Rationale
No specific rationale provided.
Vulnerable Code
check_ajax_referer( Freemius::get_ajax_action_static( 'handle_clone_resolution' ), 'security' );
$clone_action = fs_request_get( 'clone_action' );
Explanation
An authenticated low-privileged WordPress user may be able to trigger the clone-resolution AJAX action if they can load the wp-admin page that prints the clone-resolution JavaScript and nonce while clone resolution is active. The handler is wired for AJAX in _init() and accepts POST-controlled clone_action and, on multisite, blog_id.
The only visible gate before the state change is check_ajax_referer(). There is no current_user_can(), is_super_admin(), product-owner, or blog-admin authorization check before the handler calls resolve_cloned_sites( $clone_action, array(), $blog_id ). That function can store a temporary duplicate timestamp, sync an install as a new home, call long-term duplicate handling, remove notices, and send clone-resolution updates.
The impact is bounded to unauthorized Freemius clone/license/install-state changes, not general WordPress privilege escalation. Exploitation depends on clone-resolution state being present and the low-privileged user obtaining a valid nonce from an admin page; if surrounding Freemius code outside this chunk restricts the page or AJAX action to administrators, that would reduce exploitability.
Suggested Fix & Remediation
No automated remediation fix defined.
Tls Verification Disabled at ... /freemius/includes/sdk/FreemiusWordPress.php:65
Severity: medium (Score: 6.4)
Summary
Freemius API HTTPS requests disable certificate verification, allowing spoofed API responses to drive SDK state changes.
Context / Rationale
No specific rationale provided.
Vulnerable Code
if ( ! defined( 'FS_SDK__SSLVERIFY' ) ) {
define( 'FS_SDK__SSLVERIFY', false );
}
Explanation
A network-positioned attacker, malicious proxy, or compromised DNS path can intercept Freemius API traffic. The SDK defines FS_SDK__SSLVERIFY as false and later applies it to HTTPS wp_remote_request() calls, so WordPress will not authenticate the Freemius TLS certificate before accepting the response.
The controlled source is the remote HTTP response body. The API request is signed, but the visible code does not authenticate the response; it JSON-decodes and returns the body to SDK callers. A visible consumer in FS_Clone_Manager uses Freemius API results from find_other_install_by_url() to store_site() and sync_install(), so a spoofed response can alter persistent Freemius install/license context.
This finding is bounded to API response spoofing and Freemius install/license state integrity visible in this chunk. It does not claim arbitrary PHP execution or update-package compromise from the shown code alone. Exploitation requires an active network interception position or equivalent control of outbound API traffic, with no WordPress credentials and no user interaction once the site makes the API request.
Suggested Fix & Remediation
No automated remediation fix defined.
Please address all findings in your next submission. Remember that this is an automated message — do not reply to this email.
Thank you,
The WordPress Plugin Review Team (automated notification)
Heads up for the Freemius SDK team and other plugin authors submitting updates to the wordpress.org repo.
These are the security review concerns that the automated AI scanner is reporting right now in Freemius SDK 2.13.2, as part of their new supply chain attack prevention process. I realize these may be low level and not of priority concern, but I wanted to share it here and raise awareness for future versions and for other plugin authors.
On the plugin's repo page itself:
Version x.x will be released to sites in about 24 hours. WordPress.org currently delays plugin updates by 24 hours so moderators and security scanners can review changes before they reach users. If this update fixes a security issue that needs to ship sooner, contact plugins @ wordpress dot org.
I've recently updated a few other Freemius-based plugins with that banner, and it went away eventually with no email received, but here's the email I received for the first time yesterday with Freemius SDK issues added:
This is an automated security review of your latest plugin update.
Our automated security scan identified issues in the updated files that we want to bring to your attention. The items listed below may represent serious security vulnerabilities that could expose your users to potential attacks, data exposure, or unauthorized access, and we strongly recommend resolving them prior to publication in the WordPress Plugin Directory.
Please review each issue carefully and address them in your next submission.
Please do not reply to this email. This message is sent automatically and replies are not monitored. If you need to discuss the review, wait for the human reviewer's follow-up or contact the Plugin Review Team through the usual channels.
[... some plugin code stuff ...]
Remote Controlled Update at ... /freemius/includes/class-fs-plugin-updater.php:707
Severity: high (Score: 8.1)
Summary
Freemius API response controls the executable package URL injected into WordPress updates.
Context / Rationale
The cited lines do exist and do assign the remote
$new_version->urlto$update->package, which is later injected into the WordPress update transient. However, this is unmodified, standard Freemius SDK update code that ships verbatim across thousands of plugins, and fetching a package URL from the licensing/update vendor is the documented, intended purpose of the SDK. No attacker-controlled trust boundary is crossed in this plugin: the path requires compromising or controlling the Freemius API/developer account itself, plus a premium/update-eligible flow and an administrator-initiated or auto-update install. That is the inherent trust relationship of essentially every WordPress update mechanism (including core-to-wordpress.org), not a logical vulnerability or malware-like behavior in this codebase. The finding's own boundary concedes it cannot prove an arbitrary-attacker path. Under the chunk rules (remote fetch alone is insufficient; do not report legitimate disclosed update channels; do not require external compromise), this does not support a security finding.Vulnerable Code
$update->new_version = $new_version->version;
$update->url = WP_FS__ADDRESS;
$update->package = $new_version->url;
$update->tested = self::get_tested_wp_version( $new_version->tested_up_to_version );
Explanation
The remote actor is the Freemius API service, or anyone who can compromise/control the corresponding Freemius release response. The trigger is the WordPress plugin/theme update check: this class registers
pre_set_site_transient_update_pluginsandpre_set_site_transient_update_themesfilters, fetches a remote$new_version, and builds update metadata from that response.The controlled source is
$new_version->url. The visible gate checks that the remote object exists and that its URL query marks it as premium, but this code does not show package host pinning, a cryptographic signature, or a hash verification before assigning the remote URL to$update->package. That update object is then inserted into WordPress’ update transient, where core upgraders consumepackageas the ZIP to download and install.The first concrete security effect is a remote-controlled executable update source for PHP plugin/theme code. Exploitation is conditional: this is not an unauthenticated visitor path, and it does not prove direct RCE without an update being applied; it requires Freemius/developer-account/API control or compromise plus a premium/update-eligible flow, and installation still depends on an administrator action or auto-updates. The issue is therefore a supply-chain authority shift requiring human review rather than a proven arbitrary attacker vulnerability.
Suggested Fix & Remediation
No fix is proposed because the supplied evidence does not support a security finding. The code is standard Freemius SDK update behavior and the package URL originates from the trusted vendor API over the SDK's signed request layer; there is no attacker-controllable input crossing a trust boundary in this chunk. If hardening were desired independent of this audit, one could verify package host pinning and signature/hash validation already present in the broader Freemius download flow, but that requires reviewing code outside this chunk and is not warranted by the evidence shown.
Missing Capability at ... /freemius/includes/managers/class-fs-clone-manager.php:836
Severity: medium (Score: 5.5)
Summary
Clone-resolution AJAX action relies on a nonce but does not check user capability before mutating Freemius install state.
Context / Rationale
No specific rationale provided.
Vulnerable Code
check_ajax_referer( Freemius::get_ajax_action_static( 'handle_clone_resolution' ), 'security' );
$clone_action = fs_request_get( 'clone_action' );
Explanation
An authenticated low-privileged WordPress user may be able to trigger the clone-resolution AJAX action if they can load the wp-admin page that prints the clone-resolution JavaScript and nonce while clone resolution is active. The handler is wired for AJAX in
_init()and accepts POST-controlledclone_actionand, on multisite,blog_id.The only visible gate before the state change is
check_ajax_referer(). There is nocurrent_user_can(),is_super_admin(), product-owner, or blog-admin authorization check before the handler callsresolve_cloned_sites( $clone_action, array(), $blog_id ). That function can store a temporary duplicate timestamp, sync an install as a new home, call long-term duplicate handling, remove notices, and send clone-resolution updates.The impact is bounded to unauthorized Freemius clone/license/install-state changes, not general WordPress privilege escalation. Exploitation depends on clone-resolution state being present and the low-privileged user obtaining a valid nonce from an admin page; if surrounding Freemius code outside this chunk restricts the page or AJAX action to administrators, that would reduce exploitability.
Suggested Fix & Remediation
No automated remediation fix defined.
Tls Verification Disabled at ... /freemius/includes/sdk/FreemiusWordPress.php:65
Severity: medium (Score: 6.4)
Summary
Freemius API HTTPS requests disable certificate verification, allowing spoofed API responses to drive SDK state changes.
Context / Rationale
No specific rationale provided.
Vulnerable Code
if ( ! defined( 'FS_SDK__SSLVERIFY' ) ) {
define( 'FS_SDK__SSLVERIFY', false );
}
Explanation
A network-positioned attacker, malicious proxy, or compromised DNS path can intercept Freemius API traffic. The SDK defines
FS_SDK__SSLVERIFYasfalseand later applies it to HTTPSwp_remote_request()calls, so WordPress will not authenticate the Freemius TLS certificate before accepting the response.The controlled source is the remote HTTP response body. The API request is signed, but the visible code does not authenticate the response; it JSON-decodes and returns the body to SDK callers. A visible consumer in
FS_Clone_Manageruses Freemius API results fromfind_other_install_by_url()tostore_site()andsync_install(), so a spoofed response can alter persistent Freemius install/license context.This finding is bounded to API response spoofing and Freemius install/license state integrity visible in this chunk. It does not claim arbitrary PHP execution or update-package compromise from the shown code alone. Exploitation requires an active network interception position or equivalent control of outbound API traffic, with no WordPress credentials and no user interaction once the site makes the API request.
Suggested Fix & Remediation
No automated remediation fix defined.
Please address all findings in your next submission. Remember that this is an automated message — do not reply to this email.
Thank you,
The WordPress Plugin Review Team (automated notification)