I am tracking info on the RCE vulnerability on PHPMailer. I've seen that Rev. 5.2.18 has been patched for the vuln. Does that also apply to later versions as well (e.g., 5.4)?
Why ask that on here? There is no PHPMailer 5.4; The latest release is 5.2.21, which also contains a mitigation for CVE-2016-10045. You can read more about these vulnerabilities on the project wiki.
Related
The module libxml2 contained in several components of GitLab version 14.9.x is vulnerable to out-of-bounds memory writes as described in https://security-tracker.debian.org/tracker/CVE-2022-29824. GitLab seems to not patching it or mitigating the risk in the latest stable version 14.10.x. Actually I even cannot find any article on the internet about this problem in relation to GitLab.
Does anyone know why? Is it because it just does not affect GitLab?
I am using the self managed version of GitLab.
Dependabot first reported and then retracted a security problem in a package. The basis of the retraction isn't given, just that the package "is no longer vulnerable." That makes no sense. The original CVE is still out there and the affected code is still referenced.
On investigation I find that the given package is in yarn.lock twice, once in a version that contains the vulnerability and later in a version that contains the patch:
ansi-regex#^2.0.0:
version "2.1.1"
ansi-regex#^5.0.0:
version "5.0.0"````
I'd be grateful for any way to make sense of this.
If you landed on this question due to your own "no longer vulnerable" error in a different package: you may still be vulnerable.
According to one of the Dependabot maintainers, the (suspected) most common cause of "no longer vulnerable" is when you are using multiple versions of the same dependency, and one of them is vulnerable, but not the lowest version. The maintainer's post says, in part:
Here's my current understanding:
The alerts are triggered by manifest parsing code that is a separate code path from dependabot-core's parsing code. So if the
alert manifest parsing code thinks the repo is still vulnerable, the
alert will persist.
npm allows multiple versions of a dependency in the dep tree... and these are used in the code at runtime... the newest is not
superseding the old one. So if those exist, you're still vulnerable.
dependabot-core has a known bug where it only updates the lowest version of a dependency... so Dependabot may try to create a PR, then
report that npm is no longer vulnerable, when in fact a later version
of the dependency is vulnerable and is still in the tree. That's
tracked in npm erroneously reports no longer vulnerable with multiple versions of dependency. #5741
The alerts are generated based on information in the GitHub advisory database. So if that database lists all versions > 0.16.5 are
vulnerable, but the maintaner just pushed v0.17.0 which fixes the
issue, then the alert will not disappear until the advisory database
is updated. Thankfully, you can submit a PR to the advisory DB to fix
an incorrect version specifier.
So I suspect that the majority of these cases are symptoms of #5741.
Dependabot issue #5741 says:
when there is a vulnerability that affects some versions of the dependency but not the lowest version. In this case Dependabot incorrectly reports that no security update is needed.
If this source is accurate, it's because the two ansi-regex versions you've listed do not contain the vulnerability:
Confirmed 4.1.0 and 3.0.0 as affected testing using the provided reproducer. 2.1.1 does not reproduce the issue.
3.0.0 is the first affected, as that's the first version that includes 69bebf6 that the problematic part of the regex.
Thanks to answerers for your expertise.
I think the most likely diagnosis is a Dependabot bug. Generally it is wishful thinking to blame your tools but in this case it is the simplest answer by far.
We have passed Apiman-2.0.0.final through security scans and came up with some critical/high vulnerabilities, mostly relevant to keycloak-core-10.0.2.
Fixes for this vulnerability are available in higher versions of keycloak.
I would like to know how do you handle these scenarios.
Should we repackage the war locally for us to use? We can create a pull request if it works.
Should we open a Jira item? I cannot see 2.0.0 being supported on red hat Jira. https://issues.redhat.com/projects/APIMAN/summary
Please post issues on our GitHub issue tracker, not stack overflow https://github.com/apiman/apiman/issues
We're using a newer version of Keycloak for the upcoming community release. You can indeed use your own separate Keycloak instance (recommended for a real deployment), rather than the one bundled in the quickstart.
When I launch WSO2 API Manager, I get the following notice:
There are 177 updates available for the product 'wso2am-3.2.0'.[WARNING] There
are 13 critical security updates for the product 'wso2am-3.2.0'. WSO2 strongly
recommends to apply these updates in production as soon as possible.
WSO2 doesn't bundle security updates, so I head to the GitHub issues. The problem is that if I go to the security tag, I don't see anything relevant to the 3.2.0 release: https://github.com/wso2/product-apim/issues?q=label%3Asecurity+is%3Aclosed
There is one "critical for 3.2.0": https://github.com/wso2/product-apim/issues?q=label%3ASeverity%2FCritical+label%3AAffected%2F3.2.0
There are two more using this deprecated tag: https://github.com/wso2/product-apim/issues?q=label%3ASeverity%2FCritical+label%3A3.2.0
So, it seems like what you have to do is look at the 4.0 milestones and cherry-pick those fixes and backport them.
Is there a tag I am missing? Is someone bundling these?
Thanks!
You can find the security advisors in here https://docs.wso2.com/display/Security/2020+Advisories
Does the npm registry expose release notes in a standardized way? I've seen release notes in:
The README.md
On GitHub as a tagged release with no description
On GitHub as a tagged release with a description
While SemVer at least lets me know if there's a breaking change, it would be really nice to review what features or bug fixes a package author may have added.
There is no such standardization as it's completely up to the project developer(s) to define how such information is conveyed. Some might have a NEWS file, others might have a Changelog.md, or yet others may have it in the places that you mentioned. The locations and file formats can vary widely.
It is possible that npm could adopt some optional thing that can automatically display some plaintext file using some kind of fixed naming scheme (and possibly falling back to a git diff if a git repo is defined in package.json), but as of this writing there is no such feature.