Page MenuHomePhabricator

stylelint-config-wikimedia has vulnerable dependencies
Closed, ResolvedPublicSecurity


During the security review for ext:EventStreamConfig, it was discovered with's cli that stylelint-config-wikimedia has vulnerable dependencies via stylelint, namely:

  1. dot-prop@4.2.0, Prototype Pollution (medium risk)
  2. kind-of@6.0.2, Information Disclosure (low risk)
    • Introduced by stylelint-config-wikimedia@0.8.0 > stylelint@12.0.0 > global-modules@2.0.0 > global-prefix@3.0.0 > kind-of@6.0.2 and 44 other path(s). This issue was fixed in versions: 6.0.3. See also:

The low-severity Vuln-Infoleak for kind-of appears to be resolved within the latest 13.1.0 release of stylelint. The medium-severity prototype pollution vulnerability for dot-prop still exists within the aforementioned 13.1.0 release, so I've filed a security issue with them via github.

Lastly, would it be a good idea to set up a formal security reporting policy for stylelint-config-wikimedia? I believe github is the canonical repo location for this code, correct?


Author Affiliation
WMF Technology Dept

Event Timeline

Restricted Application added a project: Security. · View Herald TranscriptFeb 12 2020, 10:20 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
sbassett updated the task description. (Show Details)Feb 12 2020, 10:20 PM
sbassett added a subscriber: Reedy.

@sbassett Yes, GitHub is the canonical repo.

I fixed the second one of these in (pending merge/release).

The first one needs upstream fixes, unfortunately. dot-prop was removed from postcss-selector-parser all the way back in but stylelint is still using 3.1.1 (latest is 6.x).

sbassett changed the task status from Open to Stalled.EditedFeb 13 2020, 4:03 PM
sbassett triaged this task as Medium priority.

Update: I heard back from upstream re: postcss-selector-parser/dot-prop. There are apparently some issues upgrading stylelint to a newer version of postcss-selector-parser due to the way it parses comments. Upstream said they'd be willing to keep us (me) informed of when they're able to get a fix/upgrade in place.

@sbassett Are there security policy examples we should orient ourselves on?

@sbassett Are there security policy examples we should orient ourselves on?

For node/js dependency vulnerabilities or just in general? The Security-Team does have some developer best practices/documentation up on, though some of that is a bit dated and very PHP/MediaWiki-centric. The most relevant item might be our Third Party Code Review Checklist, which we use as a basic set of guidelines for various internal reviews. At some point, I would very much like to clean up our older documentation and craft some new documentation targeted towards other languages such as node/js, golang and python.

For the node/js dependency vulnerabilities specifically, we tend to find many of those during our security readiness reviews but would certainly encourage all technical contributors to do any of the following:

  1. run various tools like npm audit, snyk test, nvd searches, etc. manually during development cycles
  2. build npm cli commands which can run the aforementioned security checks in an automated fashion
  3. configure CI for relevant repositories to have various security checks run during code review (non-voting is fine)
  4. configure github to automatically check for relevant security alerts
  5. feel empowered to create Phab tasks like this one to request updates for vulnerable and outdated dependencies

If this isn't really what you were asking or you have any further questions, please feel free to contact us directly.

@sbasset Was referring to your last point about setting up a formal security reporting policy in the repo. AFAICT stylelint features a pretty simple[[ | file ]].

sbassett added a comment.EditedFeb 13 2020, 10:45 PM

@Volker_E Ah, ok, sorry about that. I would say any policy/ could borrow heavily from the existing Reporting Security Bugs doc (or even just link to it). Otherwise, providing an email (even better with a public key) and reminding folks that they shouldn't just open a public issue or create a pull request should suffice.

Update: upstream has tagged a new release that updates postcss-selector-parser and thus mitigates the prototype pollution vulnerability. So whenever we can upgrade stylelint-config-wikimedia to use stylelint@13.2.0, that would fix the issue on our end.

sbassett closed this task as Resolved.Feb 18 2020, 2:50 PM
sbassett assigned this task to Jdforrester-WMF.

Released as and ; I've configured LibraryUpgrader to do org-wide upgrades where possible, which all should land over the weekend, hopefully.

Excellent, thanks. I'm going to resolve and make public now.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Feb 18 2020, 2:50 PM
sbassett moved this task from Incoming to Our Part Is Done on the Security-Team board.