wp-coding-standards/wpcs

Version	Released
`3.4.1` patch	Jul 27, 2026
`3.4.0` minor 1 CVE	Jul 16, 2026
`3.3.0` minor 1 CVE	Nov 25, 2025
`3.2.0` minor 1 CVE	Jul 24, 2025
`3.1.0` minor 1 CVE	Mar 25, 2024
`3.0.1` patch 1 CVE	Sep 14, 2023
`3.0.0` major 1 CVE	Aug 21, 2023
`2.3.0` minor 1 CVE	May 13, 2020
`2.2.1` patch 1 CVE	Feb 04, 2020
`2.2.0` minor 1 CVE	Nov 11, 2019
`2.1.1` patch 1 CVE	May 21, 2019
`2.1.0` minor 1 CVE	Apr 08, 2019
`2.0.0` major 1 CVE	Jan 16, 2019
`2.0.0-RC1` pre 1 CVE	Dec 30, 2018
`1.2.1` patch 1 CVE	Dec 18, 2018
`1.2.0` minor 1 CVE	Nov 12, 2018
`1.1.0` minor 1 CVE	Sep 10, 2018
`1.0.0` major 1 CVE	Jul 25, 2018
`0.14.1` patch 1 CVE	Feb 16, 2018
`0.14.0` minor	Nov 01, 2017
`0.13.1` patch	Aug 05, 2017
`0.13.0` minor	Aug 03, 2017
`0.12.0` minor	Jul 20, 2017
`0.11.0` minor	Mar 20, 2017
`0.10.0` minor	Aug 29, 2016
`0.9.0` minor	Feb 01, 2016
`0.8.0` minor	Oct 02, 2015
`0.7.1` patch	Aug 31, 2015
`0.7.0` minor	Aug 30, 2015
`0.6.0` minor	Jun 30, 2015
`0.5.0` minor	Jun 01, 2015
`0.4.0` minor	May 01, 2015
`0.3.0` initial	Dec 11, 2014

3.4.1 patch

Jul 27, 2026

3.4.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Jul 16, 2026

3.3.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 25, 2025

3.2.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Jul 24, 2025

3.1.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Mar 25, 2024

3.0.1 patch

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Sep 14, 2023

3.0.0 major

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Aug 21, 2023

2.3.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

May 13, 2020

2.2.1 patch

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Feb 04, 2020

2.2.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 11, 2019

2.1.1 patch

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

May 21, 2019

2.1.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Apr 08, 2019

2.0.0 major

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Jan 16, 2019

2.0.0-RC1 pre

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Dec 30, 2018

1.2.1 patch

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Dec 18, 2018

1.2.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Nov 12, 2018

1.1.0 minor

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Sep 10, 2018

1.0.0 major

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Jul 25, 2018

0.14.1 patch

1 CVE

CVE-2026-45293 GHSA-3pwp-g2mj-5p3v Jul 28, 2026

WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

8.6 / 10

High

Local Low None Required Changed High High High

Impact

WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the WordPress.WP.EnqueuedResourceParameters sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host.

This affects users of the WordPress and WordPress-Extra rulesets. The WordPress-Core ruleset and the WordPress-Docs ruleset are not affected.

The vulnerability happens when the sniff checks whether the $var argument passed to functions such as wp_enqueue_script() or wp_register_script() evaluates to a falsy value. The sniff's is_falsy() method reconstructed the argument and ran it through eval(). Because of this, a maliciously crafted $ver argument such as 'system'('id') would be executed during the scan.

Patches

This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later.

Workaround

Users of the WordPress and WordPress-Extra rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an <exclude> tag to their custom ruleset (the <rule> ref value might vary depending on the ruleset):

<rule ref="WordPress">
	<exclude name="WordPress.WP.EnqueuedResourceParameters"/>
</rule>

To verify that the sniff has been disabled, run PHPCS with the -e flag, which lists all the sniffs a standard will run. WordPress.WP.EnqueuedResourceParameters should no longer appear in the output under the WordPress section:

phpcs -e --standard=/path/to/ruleset.xml

Credits

Many thanks to @FORIMOC for responsibly disclosing this vulnerability.

How can I report a security bug?

Please report security vulnerabilities privately via the "Security and quality" tab on the WPCS repository.

Affected versions


          0.14.1


          1.0.0


          1.1.0


          1.2.0


          1.2.1


          2.0.0


          2.0.0-RC1


          2.1.0


          2.1.1


          2.2.0


          2.2.1


          2.3.0

+ 6 more


            3.0.0


            3.0.1


            3.1.0


            3.2.0


            3.3.0


            3.4.0

Fixed in


          3.4.1

References

Updated Jul 28, 2026 · Source: OSV.dev

Feb 16, 2018

0.14.0 minor

Nov 01, 2017

0.13.1 patch

Aug 05, 2017

0.13.0 minor

Aug 03, 2017

0.12.0 minor

Jul 20, 2017

0.11.0 minor

Mar 20, 2017

0.10.0 minor

Aug 29, 2016

0.9.0 minor

Feb 01, 2016

0.8.0 minor

Oct 02, 2015

0.7.1 patch

Aug 31, 2015

0.7.0 minor

Aug 30, 2015

0.6.0 minor

Jun 30, 2015

0.5.0 minor

Jun 01, 2015

0.4.0 minor

May 01, 2015

0.3.0 initial

Dec 11, 2014

Activity

Reach

Details