Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apollo-server-koa: CVE-2017-1000048 vulnerability #3050

Closed
72636c opened this issue Jul 17, 2019 · 0 comments · Fixed by #3240
Closed

apollo-server-koa: CVE-2017-1000048 vulnerability #3050

72636c opened this issue Jul 17, 2019 · 0 comments · Fixed by #3240

Comments

@72636c
Copy link

72636c commented Jul 17, 2019

Description

apollo-server-koa contains a security vulnerability in its dependency tree:

apollo-server-koa@2.7.0 › koa-bodyparser@3.2.0 › co-body@4.2.0 › qs@4.0.0

Possible solution

Update to koa-bodyparser@4 per #3004. Note that this major version drops support for Node 6.

abernix added a commit that referenced this issue Aug 31, 2019
Since Node.js v6 is no longer supported by the Node.js Foundation, it was
going to come to this sooner or later since transitive packages are inching
their ECMAScript compilation targets to more and more recent versions of the
language.

While Apollo Server itself will drop support for Node.js v6 in 3.x, the
current Koa integration necessitates a more immediate exception since, after
bringing #3229 (2dd0592), the `koa-bodyparser` package was updated to a new
major version which, itself, dropped Node.js 6 support.

That update to `koa-bodyparser`, which fixes an incorrect/malformed
`Content-length` header calculation is important enough on its own, but
there's also a [CVE][1] for the [`qs`][2] dependency, which makes it even
more pressing.

We should make sure both of those are included in Apollo Server, which
currently drives the underlying version of Koa for all users because of its
close coupling with Koa itself (via the `apollo-server-koa` package).

This doesn't necessarily mean that those who are still on Node.js v6 are
completely out of luck, since they could probably modify their
`package-lock.json` files to use an older copy of `koa-bodyparser`, but
anyone still using Node.js v6 should certainly make considerations - sooner
rather than later — about upgrading to more recent and more supported
versions of Node.js!

Luckily, this micro-framework-management will soon no longer be a concern
with Apollo Server, particularly because of the introduction of a transport
abstraction, which I've proposed in #3184.

Ref: #3184

[1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000048
[2]: https://npm.im/qs

Fixes: #3050
abernix added a commit that referenced this issue Aug 31, 2019
Since Node.js v6 is no longer supported by the Node.js Foundation, it was
going to come to this sooner or later since transitive packages are inching
their ECMAScript compilation targets to more and more recent versions of the
language.

While Apollo Server itself will drop support for Node.js v6 in 3.x, the
current Koa integration necessitates a more immediate exception since, after
bringing #3229 (2dd0592), the `koa-bodyparser` package was updated to a new
major version which, itself, dropped Node.js 6 support.

That update to `koa-bodyparser`, which fixes an incorrect/malformed
`Content-length` header calculation is important enough on its own, but
there's also a [CVE][1] for the [`qs`][2] dependency, which makes it even
more pressing.

We should make sure both of those are included in Apollo Server, which
currently drives the underlying version of Koa for all users because of its
close coupling with Koa itself (via the `apollo-server-koa` package).

This doesn't necessarily mean that those who are still on Node.js v6 are
completely out of luck, since they could probably modify their
`package-lock.json` files to use an older copy of `koa-bodyparser`, but
anyone still using Node.js v6 should certainly make considerations - sooner
rather than later — about upgrading to more recent and more supported
versions of Node.js!

Luckily, this micro-framework-management will soon no longer be a concern
with Apollo Server, particularly because of the introduction of a transport
abstraction, which I've proposed in #3184.

Ref: #3184

[1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000048
[2]: https://npm.im/qs

Fixes: #3050
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant