Repository navigation
Update version comment header (1.0.5) - #7
Merged
Merged
Conversation
bueltge
approved these changes
Sep 2, 2026
Member
|
Hey @davidedammino . Thanks for the PR. We have immutable tags in our org, which means we cannot overwrite the 1.0.4 release. You need to update this header to 1.0.5. Afterward, we can create a 1.0.5 release. 👍🏻 |
davidedammino
changed the title
Contributor
Author
|
@Chrico Updated, thanks! |
Chrico
approved these changes
Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix (version metadata correction). Version 1.0.4 was tagged without updating the plugin comment header in
disable-comments.php.What is the current behavior? (You can also link to an open issue here)
Version 1.0.4 still gets identified by WordPress as 1.0.3, which is flagged as vulnerable (WPScan report). Security scanners report a false positive on sites that are actually running the patched code.
What is the new behavior (if this is a feature change)?
Comment header updated to reflect 1.0.4, so WordPress and security scanners correctly identify the installed version.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No code changes, but the existing 1.0.4 tag would need to be re-tagged to include this fix. If re-tagging isn't an option, I can update this PR to bump the version to 1.0.5 instead.
Security impact
What changed (security perspective):
No functional code changed — only the version string in the plugin comment header. This fixes version misreporting: the patched 1.0.4 release was self-identifying as 1.0.3, causing WPScan and similar tools to flag it as vulnerable. Correct reporting lets users and scanners verify they're on the patched release.
Testing done:
Confirmed the plugin now shows 1.0.4 in the WordPress admin Plugins page; diff verified as a single-line change.
Residual risk (link Jira if any):
Sites that already installed the mislabeled 1.0.4 will keep reporting as 1.0.3 until they update to the corrected release (re-tagged 1.0.4 or 1.0.5). No Jira ticket.
Other information
Full diff is one line: