I'm interested in source code vulnerabilities in my open source projects. Valid targets are listed below.
I'm not interested in any exploit that doesn't leverage a security bug in the source code, or any target that isn't on the list. Reports about clickjacking my personal website, or my DNS zone missing an SPF record, etc are not relevant.
- Any plugin listed on my WordPress.org profile.
- Overwrite Uploads
- Google Authenticator - Encourage User Activation
- CampTix Network Tools
- p2 New Post Categories
- Re-abolish Slavery Ribbon
- Rescue Children Banner
- Email Post Changes
- Force Non-SSL
- Exceptions: Manage Tags Capabilities is not covered, since I don't have commit access to fix problems with it.
- Any source repository on my Github account. Repositories that I've forked from someone else are not covered, except for those listed in the Exceptions below.
- WordPress Plugin Skeleton
- Admin Notice Helper
- WordPress Functionality Plugin Skeleton
- WordPress Skeleton
- Audit Trail Extension
- CampTix Shared Ticket Quantities
- Exceptions: wp-filemaker-api-wrapper and Scratch are not covered, because they're not finished and aren't actively being worked on. WordPress Skeleton is covered, even though it's a fork.
Critical/high severity vulnerabilities: $100. These are defined as vulnerabilities that significantly compromise the integrity of a site using the plugin. For example: privilege escalation, remote code execution, SQL injection, XSS, CSRF, etc.
Medium/low severity vulnerabilities: $25. These are defined as vulnerabilities that don't compromise the integrity of the site, but still have a significant impact on security or privacy. (e.g., gaining read access to sensitive information, etc).
To qualify, reports must have a POC or other way to show that the vulnerability can be exploited in a practical way. Please follow the standard guidelines, and I will too.
Common Invalid Reports
Front-end "XSS" from custom post types: WordPress intentionally allows Administrator and Editor accounts to enter unfiltered HTML into posts (including custom post types) and comments. It will be escaped within the Administration Panels as a precaution, but displayed raw on the front-end.
This doesn't really qualify as XSS because it requires an Administrator/Editor account in order to perform it. If someone has an Administrator/Editor account, they are already considered trusted and should be allowed to enter arbitrary HTML. If you try to reproduce the same behavior with an Author account (or other role) then it will not work.
Even if I did "fix" these, the exact same thing would be possible with standard WordPress posts, so it wouldn't make any difference. Since it requires an Administrator account, I don't think it's a relevant attack vector in real world scenarios.
For more information, please read WordPress' security FAQ.
Path Disclosure: That's really a server issue, and any competent admin will have
display_errorsdisabled on production boxes.
Version Disclosure: Hiding the names or versions of software that a service is running is just security through obscurity.
Outside Scope: Only source code bugs are within scope; vulnerabilities at the server or network layer are not in scope. Please read the Scope section above for details.
Invalid targets: My personal website is not a valid target. Please see the Targets section above for a list of valid targets.