Vulnerability in ecstatic dependency

[WayneEllery]

There is a moderate security vulnerability with ecstatic and ecstatic is no longer maintained

https://snyk.io/vuln/SNYK-JS-ECSTATIC-540354

[karlhorky]

Just ran into this.

My workaround for now is to switch my projects over to use serve.

[mattwelke]

I switched over to using Express with its static serving middleware for now. It's not that much more difficult to use than this library when using it programatically. I'll have to find something else for a quick server from the command line though. I got really used to adding http-server as a dev dependency and then using npx http-server -c-1 to serve static pages. It became a really common pattern at my company for example sites.

The creator of ecstatic has made it very clear that they don't want to maintain it anymore (jfhbrook/node-ecstatic#259). I suggest people honor their wishes and move on to another library. Perhaps http-server could use Express under the hood instead.

[asiby]

I am surprised that this is not deployed after more than two week. I switched to https://github.com/RIAEvangelist/node-http-server instead and the vulnerability issue was gone.

[asiby]

@hata6502 , ecstatic is not part of our dependencies. It's used internally by the http-server package. We have not control over it so we can't upgrade it.

[edwinm]

The vulnerable and no longer maintained ecstatic is still a dependency of http-server. Is http-server itself still maintained?

[WayneEllery]

The vulnerable and no longer maintained ecstatic is still a dependency of http-server. Is http-server itself still maintained?

Yes. It’s still maintained

[trivikr]

ecstatic is a direct dependency for http-server

http-server/package.json

Line 87 in d7bce39

"ecstatic": "^3.3.2",

As per package-lock.json, ecstatic@3.3.2 is used

http-server/package-lock.json

Lines 914 to 924 in d7bce39

	"ecstatic": {
	"version": "3.3.2",
	"resolved": "https://registry.npmjs.org/ecstatic/-/ecstatic-3.3.2.tgz",
	"integrity": "sha512-fLf9l1hnwrHI2xn9mEDT7KIi22UDqA2jaCwyCbSUJh9a1V+LEUSL/JO/6TIz/QyuBURWUHrFL5Kg2TtO1bkkog==",
	"requires": {
	"he": "^1.1.1",
	"mime": "^1.6.0",
	"minimist": "^1.1.0",
	"url-join": "^2.0.5"
	}
	},

As per GitHub advisory for CVE-2019-10775, there is no patched version available for ecstatic
GHSA-9q64-mpxx-87fg

The dep ecstatic is no longer maintained, as per jfhbrook/node-ecstatic#259

[trivikr]

Question for @thornjad who is the most active contributor for http-server, and have published recent releases:

The CVE-2019-10775 was fixed in ecstatic@v4.1.4 jfhbrook/node-ecstatic#266
Is is possible to release http-server@v0.12.4 with dependency on ecstatic@v4.1.4?

[reergymerej]

There's a PR #631 to absorb the functionality in ecstatic. If that is what we're waiting for, can we get a version bump in the interim?

Remediation: Upgrade to ecstatic@4.1.4.

The PR below bumps the version. Someone who understands ecstatic and vows can probably get the tests to pass in a matter of minutes.

[reergymerej]

FWIW, you may be able to force the resolution in the interim.
https://www.npmjs.com/package/npm-force-resolutions

Forcing the version results in npm ls balking, but the functionality appears to work. Worth a shot.

Addendum

The library does change the ecstatic version, but then http-server doesn't work. Cool trick, though.