Regarding the Vega Lite plugin - from Human Made:
"These are the versions of the Vega libraries that we use on the WordPress plugin:

"vega": "^5.22.1",
"vega-embed": "^6.21.0",
"vega-lite": "^5.2.0""

My understanding is those versions avoid the security issues raised with the Graphs extension.

Hey @Varnent - Is there any pressing deadline or milestone guiding this work right now? I ask because, given other security issues and our current reviews commitment for this quarter, we might not be able to perform this review until next quarter.

Hey @sbassett - thank you for looking into this quickly. We have some work on hold pending the additional plugins. They are - fwiw - either all already in use elsewhere or approved already by the web host (VIP).

I am okay with Comms taking responsibility for problems with their usage until Security has time to do a review of everything - and then we can huddle on what changes - if any - need to be made to the collection of plugins as a whole.

If that works for you - then we do not have any pressing deadlines. If you would like us to freeze adding any new plugins until everything is reviewed - we may want to see if we can squeeze at least those plugins in as soon as reasonably possible.

Adding in org's primary WordPress vendor for visibility/awareness.

Security Review Summary - T335004 - 2023-09-26

In general, the vendor code presently under evaluation raises certain concerns. This is primarily due to the fact that the primary avenue for potential attacks on WordPress installations is through plugins. In the list of plugins being assessed, some raise security red flags, notably those with low usage and maintenance levels (please refer to the detailed analysis below).

On a positive note, the provided testing environment has undergone thorough testing, and it seems that all the plugins are not in vulnerable versions (please provide the exact version list to double check). To mitigate the overall risk, it is imperative to consistently keep all plugins to their latest versions. This proactive approach will help maintain a secure WordPress installation.

To further lower the risk, it is strongly suggested to reduce the number of outdated and vulnerable dependencies. It is also suggested to make some efforts to address some of the SAST findings in the files attached, even though we may not directly own the code. Collaborative efforts to resolve these findings can significantly enhance the overall security posture.

One aspect I'm uncertain about is whether the Shiro theme currently in use is up to date. It appears that the current version is 1.0.0, while the latest available version is 1.1.3?

To address privacy concerns, the following three plugins: multilingualpress, yoast and gravity forms will undergo a comprehensive review by Privacy Engineering.

Overall risk rating of: medium

PublishPress Permissions

Gf-hcaptcha

Safe-svg

Broken-link-checker

Co-authors-plus

Safe-redirect-manager

Duplicate-page

Fieldmanager

Vulnerable Packages
none

General Security Issues

Maintenance-mode-wp

Vulnerable Packages
none

General Security Issues

Simple-editorial-comments

Vulnerable Packages
none

General Security Issues

Vegalite-wordpress-plugin

Vulnerable Packages

General Security Issues

Asset-loader

Vulnerable Packages
none

General Security Issues

Hm-gutenberg-tools

Vulnerable Packages

General Security Issues

Wikipedia-preview

Vulnerable Packages

General Security Issues

Hi @Varnent - Do you have any plan to mitigate these issues?

Looping in @SCampos-WMF and @CKoerner_WMF - Chris is lead on Diff, which may be impacted as well. Sara is new lead on the org's WordPress websites and I will be meeting with tomorrow about next steps.

Pinging @Varnent, @SCampos-WMF and @CKoerner_WMF again. With an overall risk rating of medium, we'll either need some acknowledgement of a mitigation plan to address these issues or the medium risk will be added to our risk register as being accepted by Lisa McCabe and/or @Ospingou per our current risk management framework.

Hey @sbassett, please apologize for the delayed response. We've created a ticket for Human Mande to enhance the security levels of their own plugins, and to get in touch with the third-party plugin developers to highlight the identified security vulnerabilities and request the necessary improvements. This is a top-priority item and is currently part of our ongoing Sprint. Our team is actively engaged in implementing the required security measures. Thanks for your understanding!

@SCampos-WMF - Sounds good. Until that work is completed, we will have an entry for a medium risk within our application security risk register, currently jointly owned by Lisa McCabe and Olga Spingou.

I am adding @SBisson to this ticket, for further visibility on WikiPreview security recommendations and action items.

Hi @SCampos-WMF - What's the progress on the remediation plan? Kindly provide an update so that we can prevent adding it to our risk registry. Thank you.

Hi @sbassett I see in the Wikipedia Preview analysis that a "Policy/Methods for reporting security issues" is missing and that is listed as medium. Could you advice on how to address this?

About the long list of vulnerable packages, this is a forever battle for our team. We have a monthly "npm audit" on all of our actively maintained products, that includes Wikipedia Preview, but these vulnerabilities seem to be coming out of nowhere often without any dependencies change on our side. We have started simplifying our build process to reduce the number of dependencies and hopefully decrease the auditing workload but we have yet to see the results.

thanks

In T335004#9451492, @SBisson wrote:

Hi @sbassett I see in the Wikipedia Preview analysis that a "Policy/Methods for reporting security issues" is missing and that is listed as medium. Could you advice on how to address this?

So this would generally only concern upstream packages. If we see that there is no security policy set up within their github (or wherever) repo, then we generally determine that to be a medium risk. This is a check that we've borrowed verbatim from scorecard. There isn't much actionable here on the WMF's/Community's part, save submitting a PR or email to the upstream developers requesting that they create a security policy, SECURITY.md, etc. (See also).

About the long list of vulnerable packages, this is a forever battle for our team. We have a monthly "npm audit" on all of our actively maintained products, that includes Wikipedia Preview, but these vulnerabilities seem to be coming out of nowhere often without any dependencies change on our side. We have started simplifying our build process to reduce the number of dependencies and hopefully decrease the auditing workload but we have yet to see the results.

Yes, vulnerable dependencies are something we still check for during most security reviews, but we understand the issues for developers when it comes to actually addressing said vulnerabilities. We certainly do not expect that WMF/Community developers submit endless upstream pull/merge requests to address these issues. Nor do we expect developers to perform detailed reachability analyses to see if certain dependencies are indeed vulnerable within our codebases or not (on this front, we do have access to the semgrep's supply-chain tool, which is sometimes helpful in automating such determinations). Beyond that, we just ask that certain risks related to any vulnerable dependency findings be accepted by a manager or director, and that engineers follow the best practices you've essentially described above: due-diligence to fix vulnerable dependencies when feasible, writing more pure code that doesn't leverage numerous dependencies (especially for node/npm) and just general awareness around vulnerable dependencies, e.g. a dev dependency with an unreachable XSS versus a production dependency with very reachable authorization vulnerabilities.

In T335004#9449562, @mmartorana wrote:

Hi @SCampos-WMF - What's the progress on the remediation plan? Kindly provide an update so that we can prevent adding it to our risk registry. Thank you.

Hi team, thank you for the review! Following your recommendations, we've minimized the number of outdated and vulnerable dependencies and resolved the findings identified in the SAST files you provided. Additionally, we reached out to plugin developers to bring attention to the vulnerabilities and issues. Moving forward, our plan is to complete the remaining tasks associated with two plugins we maintain, HM Gutenberg Tools and Vega Lite, during our upcoming sprints in January and February. Additionally, we plan to update outdated plugins to versions released since our last sprint in December. For a more comprehensive breakdown, please review the details of each action we've taken below:

@mmartorana to answer your question:

One aspect I'm uncertain about is whether the Shiro theme currently in use is up to date. It appears that the current version is 1.0.0, while the latest available version is 1.1.3?

We actually do not use the Shiro theme available on WordPress, our theme is owned and maintained by us, it is called the same as the one you found. We will update its name to Wikimedia Shiro, to separate from the existing WordPress Shiro.

We have also deployed the first version of our Security Plugin, which was crafted based on the results of previous code reviews and recommendations you shared with us. This plugin, designed to consistently control and apply the same security changes to current and potential new Wikimedia WordPress projects, has been installed in the production environment on the WMF website. Currently, we are in the process of extending the deployment to Diff and the Endowment website. Additionally, we plan to deploy it on Messaging Guide and Techblog during the February and March sprints. The Security Plugin handles these cases:

• Set CSP headers (customizable per-site in code, if sites should allow more or fewer supported origins)
• Set a variety of other headers to achieve various security goals, like enforcing HTTPS connections, preventing clickjacking attacks, blocking MIME type sniffing, controlling referrer information sharing, and restricting permission policies for specific features.
• Lock down anonymous REST API access
• Disable Jetpack Blaze
• Disable emoji by bundling the Disable Emoji plugin

Additionally, we have contacted plugin developers to request changes:

• Wikipedia Preview (by Wikipedia): We shared the issues with the Inuka Team, and added @SBisson to this thread for more visibility.
• Fieldmanager (by Alley Interactive): During our December Sprint, we shared with Alley Interactive’s development team the issues found in their code. They acknowledged the receipt of our request and mentioned they’ll review it. We plan to follow up with them this month. If they are unable to address the security issues for any reason, we plan to propose opening a pull request in their codebase, or writing a composer patch to fix the issue on our codebase as a last option.
• Maintenance Mode WP (by Automattic / WordPress VIP): During our December Sprint, we shared with Automattic’s development team the issues found in their code. They acknowledged the receipt of our request and mentioned they’ll review it. We plan to follow up with them this month. If they are unable to address the security issues for any reason, we plan to propose opening a pull request in their codebase, or writing a composer patch to fix the issue on our codebase as a last option.

During January’s sprint we will update specific Composer-managed WordPress plugins to their latest versions:

• Asset Loader from 0.6.4 to 0.7.0.
• Broken Link Checker from 2.2.3 to 2.2.4.
• Fieldmanager from 1.5.0 to 1.6.0.
• Gravity Forms from 2.7.15 to 2.8.1.
• HM Gutenberg Tools from 1.7.2 to 1.7.3.
• Safe Redirect Manager from 2.1.0 to 2.1.1.
• Wikipedia Preview from 1.11.0 to 1.12.0.
• Yoast SEO from 21.6 to 21.7.

Below, you will see what we've done so far and what we're planning to complete within Q3. Thank you for taking the time to review, we are looking forward to your comments:
PublishPress Permissions

• Version: Up to date, we are using version 3.11.5.
• No vulnerable NPM dependencies.
• No code findings.
• No action needed.

Safe-svg

• Version: Up to date, we are using version 2.2.2.
• No vulnerable NPM dependencies.
• The latest release is believed to address the flagged issues.
• No code findings.
• No action needed.

Broken Link Checker

• Version: Using version 2.2.3, we will update to the newest version 2.2.4 during January Sprint.
• No vulnerable NPM dependencies.
• The latest release is believed to address the flagged issues.
• No code findings.
• No action needed.

Co Authors Plus

• Version: Up to date, we are using version 3.5.15.
• No vulnerable NPM dependencies.
• The disclosed vulnerabilities were not found.
• No code findings.
• No action needed.

Safe Redirect Manager

• Version: Using version 2.1.0, we will update to the newest version 2.1.1 during January Sprint.
• No vulnerable NPM dependencies.
• No code findings.
• No action needed.

Gravity Forms

• Version: Using version 2.8.0, we will update to the newest version 2.8.1 during January Sprint.

Yoast SEO

• Version: Using version 21.7, we will update to the newest version 21.8 during January Sprint.

Duplicate Page

• We did not find this on the used plugins list.

Solved issues

Simple Editorial Comments

• Version: Up to date, we are using version 0.1.1.
• No vulnerable NPM dependencies

All actions were solved by Human Made team during November & December Sprints:

• Fix all the SAST Audit code findings
• Check if everything is working as expected
• Publish a new release
• Update to newest version 0.1.1

Issues: SAST Audit

• .github/workflows/php-standards.yml
• Line 25: uses: shivammathur/setup-php@2.7.0 - Third-party action not pinned to commit SHA (Details)

• .github/workflows/release.yml
• Line 22: uses: technote-space/release-github-actions@v7 - Third-party action not pinned to commit SHA (Details)

Asset Loader

• Version: We are using version 0.6.4, we will update to the newest version 0.7.0 during January Sprint.
• No vulnerable dependencies

All actions were solved by Human Made team during November & December Sprints:

• Fix all the SAST Audit code findings
• Check if everything is working as expected
• Publish a new release
• Update to newest version 0.6.4

Issues: SAST Audit

• .github/workflows/deploy-docs.yml
• Line 27: ruby/setup-ruby@v1 - Third-party action not pinned to commit SHA (Details)
• docs/404.html
• Line 11: Template variable in 'href' attribute - Risk of XSS attack via 'javascript:' URI (Details)
• Line 11: Template variable in 'href' attribute - XSS risk (Details1 Details2)

In progress, will be solved during Q3 Sprints
Gf-hcaptcha

• Version: Up to date, we are using version 1.3.1
• No vulnerable NPM dependencies
• No code findings
• No action needed

The overall maintenance score, considering factors such as total reviews, code frequency, recent contributions to code, active developers, current overall usage, and issues resolved in the last two months, is not satisfactory. While these issues may not be code vulnerabilities, we recognize that they erode our trust in this plugin. Our mitigation plan is to explore alternative options during Q3 that meet our requirements and have a better maintenance record. We will share more about this in the coming months.

Vega Lite

• Needs update (using 0.2.1)

Solved and pending actions by Human Made team:

• Fix all the SAST Audit code findings
• Upgrade and check the vulnerable NPM dependencies
• Check if everything is working as expected
• Publish a new release
• Update to newest version 0.3.0

Issues: SAST Audit

• .github/workflows/php-standards.yml
• Line 25: shivammathur/setup-php@2.7.0 - Third-party action not pinned to commit SHA (Details)
• .github/workflows/release.yml
• Line 22: technote-space/release-github-actions@v7 - Third-party action not pinned to commit SHA (Details)

• assets/vega-embed.6.20.2.js- Potentially fixed, this will require another SAST scan to confirm it's fixed.
• Use of RegExp with a t function argument - Potential Regular Expression Denial-of-Service (ReDoS) (Details)
• Use of RegExp with a e function argument - Potential Regular Expression Denial-of-Service (ReDoS) (Details)
• Prototype pollution possibility detected via c=c[g] (Details)

• assets/vega-lite.5.2.0.js - Potentially fixed, this will require another SAST scan to confirm it's fixed.
• Use of RegExp with a c function argument - Potential Regular Expression Denial-of-Service (ReDoS) (Details)
• Use of RegExp with a t function argument - Potential Regular Expression Denial-of-Service (ReDoS) (Details)

Vulnerable NPM dependencies

• semver (6.3.0) - https://osv.dev/GHSA-c2qf-rxjj-qqgw (version not affected, vulnerability introduced on 7.0.0)
• semver (7.3.8) - https://osv.dev/GHSA-c2qf-rxjj-qqgw (fixed on 7.5.2 - upgraded to 7.5.4)
• vega (5.22.1) - https://osv.dev/GHSA-4vq7-882g-wcg4 (fixed on 5.13.1 - upgraded to 5.26.1)
• vega (5.22.1) - https://osv.dev/GHSA-w5m3-xh75-mp55 (fixed on 5.23.0 - upgraded to 5.26.1)
• vega-functions (5.13.0) - https://osv.dev/GHSA-4vq7-882g-wcg4 (fixed on 5.13.1 - upgraded to 5.14.0)
• vega-functions (5.13.0) - https://osv.dev/GHSA-w5m3-xh75-mp55 (fixed on 5.23.0)
• webpack (5.75.0) - https://osv.dev/GHSA-hc6q-2mpp-qw7j (fixed on 5.76.0 - upgraded to 5.89.0)
• word-wrap (1.2.3) - https://osv.dev/GHSA-j8xg-fqg3-53r7 (fixed on 1.2.4 - upgraded to 1.26.0)

HM Gutenberg Tools

• Version: Using version 1.7.2, we will update to the newest version 1.7.3 during January Sprint.

Solved and pending actions by Human Made team:

• Fix all the SAST Audit code findings
• Upgrade and check the vulnerable NPM dependencies
• Check if everything is working as expected
• Publish a new release
• Update to newest version 1.7.2
• Upgrade vulnerable transitive dependencies

Issues: SAST Audit

• js/post-select/components/post-list-item.js
• Line 30: Use of dangerouslySetInnerHTML with post.title.rendered - Potential XSS risk (Details)
• js/post-select/components/selection-item.js
• Line 27: Use of dangerouslySetInnerHTML with post.title.rendered - Potential XSS risk (Details)

Vulnerable NPM dependencies

• ajv (4.11.8) - https://osv.dev/GHSA-v88g-cgmw-v5xw (transitive dependency of eslint-plugin-class-property)
• decode-uri-component (0.2.0) - https://osv.dev/GHSA-w573-4hg7-7wgq (fixed on 0.2.1, upgraded to 0.2.2)
• glob-parent (3.1.0) - https://osv.dev/GHSA-ww39-953v-wcq6 (transitive dependency of chokidar)
• jsdom (11.12.0) - https://osv.dev/GHSA-f4c9-cqv8-9v98 (not found)
• json5 (1.0.1) - https://osv.dev/GHSA-9c47-m6qq-7p4h (fixed on 2.2.2 - upgraded to 2.2.3)
• json5 (2.2.1) - https://osv.dev/GHSA-9c47-m6qq-7p4h (fixed on 2.2.2 - upgraded to 2.2.3)
• loader-utils (1.4.0) - https://osv.dev/GHSA-76p3-8jx3-jpfq (not affected)
• loader-utils (1.4.0) - https://osv.dev/GHSA-3rfm-jhwj-7488 (fixed on 1.4.2 - upgraded to 1.4.2)
• loader-utils (1.4.0) - https://osv.dev/GHSA-hhq3-ff78-jv3g (fixed on 1.4.2 - upgraded to 1.4.2)
• loader-utils (2.0.2) - https://osv.dev/GHSA-76p3-8jx3-jpfq (fixed on 2.0.3 - upgraded to 2.0.4)
• loader-utils (2.0.2) - https://osv.dev/GHSA-3rfm-jhwj-7488 (fixed on 1.4.2 - upgraded to 1.4.2/2.0.4)
• loader-utils (2.0.2) - https://osv.dev/GHSA-hhq3-ff78-jv3g (fixed on 1.4.2 - upgraded to 1.4.2/2.0.4)
• node-forge (0.10.0) - https://osv.dev/GHSA-5rrq-pxf6-6jx5 (transitive dependency of selfsigned)
• node-forge (0.10.0) - https://osv.dev/GHSA-8fr3-hfg3-gpgp (transitive dependency of selfsigned)
• node-forge (0.10.0) - https://osv.dev/GHSA-gf8q-jrpm-jvxq (transitive dependency of selfsigned)
• node-forge (0.10.0) - https://osv.dev/GHSA-2r2c-g63r-vccr (transitive dependency of selfsigned)
• node-forge (0.10.0) - https://osv.dev/GHSA-cfm4-qjh2-4765 (transitive dependency of selfsigned)
• node-forge (0.10.0) - https://osv.dev/GHSA-x4jg-mjrx-434g (transitive dependency of selfsigned)
• node-notifier (5.4.5) - https://osv.dev/GHSA-5fw9-fq32-wv5p (not found)
• nth-check (1.0.2) - https://osv.dev/GHSA-rp65-9cf3-cjxr (transitive dependency of css-select)
• request (2.88.2) - https://osv.dev/GHSA-p8p7-x288-28g6 (not found)
• semver (5.7.1) - https://osv.dev/GHSA-c2qf-rxjj-qqgw (not affected - fixed on 7.5.2 - upgraded to 5.7.2/7.5.4)
• semver (6.3.0) - https://osv.dev/GHSA-c2qf-rxjj-qqgw (not affected - fixed on 7.5.2 - upgraded to 6.3.1/7.5.4)
• semver (7.3.8) - https://osv.dev/GHSA-c2qf-rxjj-qqgw (fixed on 7.5.2 - upgraded to 7.5.4)
• shelljs (0.7.8) - https://osv.dev/GHSA-4rq4-32rv-6wp6 (fixed on 0.8.5 - transitive dependency of eslint)
• shelljs (0.7.8) - https://osv.dev/GHSA-64g7-mvw6-v9qj (fixed on 0.8.5 - transitive dependency of eslint)
• tough-cookie (2.5.0) - https://osv.dev/GHSA-72xf-g2v4-qvf3 (not found)
• word-wrap (1.2.3) - https://osv.dev/GHSA-j8xg-fqg3-53r7 (fixed on 1.2.4 - upgraded to 1.2.5)

Hi @SCampos-WMF - Thanks for letting us know. The security posture is improved, and I see that you have a plan to address the remaining issues. I can now assign a low risk score.

Please keep us informed, and feel free to reach out if you require further assistance.

Thank you @mmartorana! We will keep you informed once we finish deploying the updates!