nexB
RFC: Improve API with a new V2 for packages
I suggest we simplify and evolve the API to a version 2 that would return this data shape, when querying the packages/ endpoint for one or more PURLs.
We would enable filters based on PURL components and whole PURLs, as well as "affected by" or "fixing" VCID. This would replace all the packages/ endpoints, and would privilege the primary use case: lookup by PURL.
purls:
- purl: pkg:apache/[email protected]
affected_by_vulnerabilities:
- VCID-2spt-jvsb-aaak
- VCID-je6z-ydc6-aaap
- VCID-z4hk-71j3-aaar
fixing_vulnerabilities: []
next_non_vulnerable_purl:
latest_non_vulnerable_purl:
- purl: pkg:apache/[email protected]
affected_by_vulnerabilities:
- VCID-2spt-jvsb-aaak
- VCID-2wjk-ntty-aaab
- VCID-9qha-2aq6-aaap
fixing_vulnerabilities:
- VCID-2spt-jvsb-aaak
- VCID-2wjk-ntty-aaab
next_non_vulnerable_purl:
latest_non_vulnerable_purl:
vulnerabilities:
- vulnerability_id: VCID-18z2-2yw1-aaaj
aliases:
- CVE-2010-2263
summary: Vulnerabilities with Windows file default stream
severities: []
weaknesses: []
references:
- url: https://nvd.nist.gov/vuln/detail/CVE-2010-2263
reference_type:
reference_id: CVE-2010-2263
- vulnerability_id: VCID-1dsf-ryt7-aaan
aliases:
- CVE-2000-0913
summary: 'The Rewrite module, mod_rewrite, can allow access to any file on the web server. The
vulnerability occurs only with certain specific cases of using regular expression references
in RewriteRule directives: If the destination of a RewriteRule contains regular expression
references then an attacker will be able to access any file on the server.'
severities:
- score: important
scoring_system: apache_httpd
scoring_elements:
published_at:
reference:
url: https://httpd.apache.org/security/json/CVE-2000-0913.json
reference_type:
reference_id: CVE-2000-0913
weaknesses: []
references:
- url: https://httpd.apache.org/security/json/CVE-2000-0913.json
reference_type:
reference_id: CVE-2000-0913
When querying the vulnerabilities/ endpoint for one or more VCID, we would return the "vulnerabilities" section above. We could enable a filter based on an exact alias value, like a CPE or keep it as a separate endpoint. This would otherwise replace all endpoints on vulnerabilities/ as the main endpoint is packages/
The benefits is that a simple API call will return all the needed data, but there are no complex inlining or nesting of the data.
@pombredanne The new structure looks fine. I would suggest that we introduce a new endpoint for now instead of a full API v2.
Also, the vulnerabilities should be a mapping by VCID to make it easier on the client to consume the data.
We could get the vulnerabilities section this way then:
vulnerabilities_by_id:
VCID-18z2-2yw1-aaaj:
vulnerability_id: VCID-18z2-2yw1-aaaj
aliases:
- CVE-2010-2263
summary: Vulnerabilities with Windows file default stream
severities: []
weaknesses: []
references:
- url: https://nvd.nist.gov/vuln/detail/CVE-2010-2263
reference_type:
reference_id: CVE-2010-2263
VCID-1dsf-ryt7-aaan:
vulnerability_id: VCID-1dsf-ryt7-aaan
aliases:
- CVE-2000-0913
summary: 'The Rewrite module, mod_rewrite, can allow access to any file on the web server.
The vulnerability occurs only with certain specific cases of using regular expression
references in RewriteRule directives: If the destination of a RewriteRule contains regular
expression references then an attacker will be able to access any file on the server.'
severities:
- score: important
scoring_system: apache_httpd
scoring_elements:
published_at:
reference:
url: https://httpd.apache.org/security/json/CVE-2000-0913.json
reference_type:
reference_id: CVE-2000-0913
weaknesses: []
references:
- url: https://httpd.apache.org/security/json/CVE-2000-0913.json
reference_type:
reference_id: CVE-2000-0913
I've noticed that the weaknesses data is available in the /api/vulnerabilities/ details endpoint but not in the packages one. This is problematic for data collection through the API.
Make sure to include it in this new endpoint implementation.
https://gist.github.com/pombredanne/17783e9d2eca885b767f5fbe3d96eec4 - for vulnerabilities design
Next Step-
VulnerabilitytoaPackage relationship:
api/affected_by_package/?vulnerabiltiy=VCID&package=purl api/fixing_packages/?vulnerabiltiy=VCID&package=purl
To recap here is the design that I suggest for the API calls:
We have two endpoints:
- Package endpoint: For packages, we always return a list of packages using the structure designed in https://github.com/aboutcode-org/vulnerablecode/issues/1572#issue-2489016050
- The main filter is for one or more packages.
- We can also filter by
affected_by_vulnerabilitywhere we pass a VCID and get only the packages that are affected - OR filter by
fixing_vulnerabilitywhere we pass a VCID and get only the packages that are fixing this VCID - We could in the future also include query by VCID aliases
- Vulnerability endpoint: for vulnerabilities this is only returning the "vulnerabilities_by_id" data as explained in https://github.com/aboutcode-org/vulnerablecode/issues/1572#issuecomment-2326064394
- this can be filtered for one or many VCID, but no package. We could also filter by alias (to filter for CVE)
- this is not for browsing, so the "list" endpoint should only list VCIDs and no details
@TG1999 @pombredanne In DejaCode, we need to fetch over 500,000 PURLs daily from VulnerableCode. For each, I need the list of affected_by_vulnerabilities and full details of each vulnerability. Can you provide the most efficient way to do this using the current v2 implementation?
Here is what we could do for efficient retrieval:
We have a package endpoint and we can request a list of 500K purls
From there, we could either:
- collect all the referenced VCIDs and call a vulnerability details endpoint, passing all these VCIDs, OR
- call a vulnerability details endpoint passing all the 500K PURLs, OR
- call the package endpoint as abobe but with an extra flag: "include vulnerability details" in which case we would return something of this shape:
packages:
"purl": "pkg:pypi/[email protected]",
"affected_by_vulnerabilities": ["VCID-486n-st7z-zqhz"],
"fixing_vulnerabilities": [],
"next_non_vulnerable_version": "4.3",
"latest_non_vulnerable_version": "5.2"
.....
(repeat for each queried package)
vulnerabilities:
- VCID-486n-st7z-zqhz
"vulnerability_id": "VCID-112b-d97c-rbe4",
"aliases": ["CVE-2021-37659", ...],
"summary": "TensorFlow is an end-to-end open source....",
"severities": [],
"weaknesses": [],
....
(repeat for each vulnerability VCID referenced in the packages)
Also to be very clear: I want to avoid inlining package data under a vulnerability. e.g., we may not get counts and fixed or affected packages there ... but instead we have the same data by package, and the vulnerability details is just that and not further containing counts or inlines of package data.
So you would not get these https://github.com/aboutcode-org/dejacode/blob/7dd0b167cd3bb1993c17daef557ff9bcd5b28955/vulnerabilities/models.py#L88-L96
@tdruez
"purl_only": false, "plain_purl": false
Do we still use these parametes in DJCD for bulk search and do we need to support them in V2 ?
{
"purls": ["pkg:pypi/[email protected]"],
"purl_only": false,
"plain_purl": false
}
For this I/P in V2 bulk search API
{
"vulnerabilities": {
"VCID-486n-st7z-zqhz": {
"vulnerability_id": "VCID-486n-st7z-zqhz",
"aliases": [
"CVE-2021-32807",
"CVE-2021-32811",
"GHSA-g4gq-j4p2-j8fr",
"GHSA-qcx9-j53g-ccgf",
"PYSEC-2021-335",
"PYSEC-2021-368",
"PYSEC-2021-370",
"PYSEC-2021-875"
],
"summary": "The module `AccessControl` defines security policies for Python code used in restricted code within Zope applications. Restricted code is any code that resides in Zope's object database, such as the contents of `Script (Python)` objects. The policies defined in `AccessControl` severely restrict access to Python modules and only exempt a few that are deemed safe, such as Python's `string` module. However, full access to the `string` module also allows access to the class `Formatter`, which can be overridden and extended within `Script (Python)` in a way that provides access to other unsafe Python libraries. Those unsafe Python libraries can be used for remote code execution. By default, you need to have the admin-level Zope \"Manager\" role to add or edit `Script (Python)` objects through the web. Only sites that allow untrusted users to add/edit these scripts through the web - which would be a very unusual configuration to begin with - are at risk. The problem has been fixed in AccessControl 4.3 and 5.2. Only AccessControl versions 4 and 5 are vulnerable, and only on Python 3, not Python 2.7. As a workaround, a site administrator can restrict adding/editing `Script (Python)` objects through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing these scripts through the web should be restricted to trusted users only. This is the default configuration in Zope.",
"severities": [],
"weaknesses": [],
"references": [
{
"url": "https://github.com/zopefoundation/AccessControl/blob/master/CHANGES.rst#51-2021-07-30",
"reference_type": "",
"reference_id": ""
},
{
"url": "https://github.com/zopefoundation/AccessControl/commit/b42dd4badf803bb9fb71ac34cd9cb0c249262f2c",
"reference_type": "",
"reference_id": ""
},
{
"url": "https://github.com/zopefoundation/AccessControl/security/advisories/GHSA-qcx9-j53g-ccgf",
"reference_type": "",
"reference_id": ""
},
{
"url": "https://github.com/zopefoundation/Zope/commit/f72a18dda8e9bf2aedb46168761668464a4be988",
"reference_type": "",
"reference_id": ""
},
{
"url": "https://github.com/zopefoundation/Zope/security/advisories/GHSA-g4gq-j4p2-j8fr",
"reference_type": "",
"reference_id": ""
}
]
}
},
"packages": [
{
"purl": "pkg:pypi/[email protected]",
"affected_by_vulnerabilities": [
"VCID-486n-st7z-zqhz"
],
"fixing_vulnerabilities": [],
"next_non_vulnerable_version": "4.3",
"latest_non_vulnerable_version": "5.2"
}
]
}
You will get this O/P
Also to be very clear: I want to avoid inlining package data under a vulnerability. e.g., we may not get counts and fixed or affected packages there ... but instead we have the same data by package, and the vulnerability details is just that and not further containing counts or inlines of package data.
So you would not get these https://github.com/aboutcode-org/dejacode/blob/7dd0b167cd3bb1993c17daef557ff9bcd5b28955/vulnerabilities/models.py#L88-L96
@pombredanne I've noticed that certain features in the DejaCode UI rely on the fixed_packages data provided by VCIO.
- Are you indicating that this data will no longer be available? If so, this would have a significant impact on DejaCode.
- Or will the data still be accessible, but only through the
packagesendpoint? I'm seeking clarification as I haven't observed any mention offixed_packagesin the current v2 progress.
Do we still use these parametes in DJCD for bulk search and do we need to support them in V2 ?
Yes, both are used on the DejaCode side. Although with the new API structure, those may not be needed anymore, to be confirmed. You can keep those out of the v2 implementation and I will keep you posted once the DejaCode code is getting migrated to work on v2.
wrt. https://github.com/aboutcode-org/vulnerablecode/issues/1572#issuecomment-2475578554 ... I think we need something a bit different.
We have this today:
"packages": [
{
"purl": "pkg:pypi/[email protected]",
"affected_by_vulnerabilities": [
"VCID-486n-st7z-zqhz"
],
"fixing_vulnerabilities": [],
"next_non_vulnerable_version": "4.3",
"latest_non_vulnerable_version": "5.2"
}
]
Are we missing a "fixed by" that is just for a vulnerability-package? May be something like that?
"packages": [
{
"purl": "pkg:pypi/[email protected]",
"affected_by_vulnerabilities": [
{
"vulnerability_id": "VCID-486n-st7z-zqhz",
"fixed_by_package": "pkg:pypi/[email protected]",
}
],
"fixing_vulnerabilities": [],
"next_non_vulnerable_package": "4.3",
"latest_non_vulnerable_package": "5.2"
}
]
with these definitions:
- fixed_by_package: a PURL for the first version that is fixing just one vulnerability
- next_non_vulnerable_package: a PURL for the first version that is non vulnerable to any vulnerability
- latest_non_vulnerable_package: a PURL for the latest version that is non vulnerable to any vulnerability
Question: would this reintroduce nesting?
This is completed in this PR https://github.com/aboutcode-org/vulnerablecode/pull/1631
We have 2 new endpoints deployed and live on https://public.vulnerablecode.io/api/v2/
- /api/v2/packages - https://public.vulnerablecode.io/api/v2/packages
- /api/v2/vulnerabilities- https://public.vulnerablecode.io/api/v2/packages
Packages endpoint- This endpoint has three filters
- affected_by_vulnerability - where we pass a VCID and get only the packages that are affected
- fixing_vulnerability - where we pass a VCID and get only the packages that are fixing this VCID
- purl - where we pass purl and get information about that PURL
Format:
https://public.vulnerablecode.io/api/v2/packages
If you see the above example:
- In results, we now provide "vulnerabilities" and "packages", where "vulnerabilities" contains data on all vulnerabilities that might be fixed by those packages or affecting those packages.
- For a single package format looks like this:
{
"purl": "pkg:cargo/[email protected]",
"affected_by_vulnerabilities": [
"VCID-vyuz-5w1k-mqce"
],
"fixing_vulnerabilities": [],
"next_non_vulnerable_version": "1.12.2",
"latest_non_vulnerable_version": "1.12.2",
"risk_score": 4.0
}
Vulnerabilities endpoint- This endpoint has two filters
- alias - where we pass an alias and get vulnerability IDs associated with that alis
- vulnerability_id - where we pass vulnerability ID and get info for the VCID
Format:
https://public.vulnerablecode.io/api/v2/vulnerabilities
- In results, we now provide "vulnerabilities" map which has key as VCID and value in this format
{
"vulnerability_id": "VCID-111c-u9bh-aaac",
"url": "http://public.vulnerablecode.io/api/v2/vulnerabilities/VCID-111c-u9bh-aaac"
}
- The above "url" points to information about that vulnerability ID
- For a single Vulnerability ID http://public.vulnerablecode.io/api/v2/vulnerabilities/VCID-111c-u9bh-aaac format looks like this
{
"vulnerability_id": "VCID-111c-u9bh-aaac",
"aliases": [
"CVE-2017-1000136"
],
"summary": "Mahara 1.8 before 1.8.6 and 1.9 before 1.9.4 and 1.10 before 1.10.1 and 15.04 before 15.04.0 are vulnerable to old sessions not being invalidated after a password change.",
"severities": [
{
"url": "https://api.first.org/data/v1/epss?cve=CVE-2017-1000136",
"value": "0.00083",
"scoring_system": "epss",
"scoring_elements": "0.36574",
"published_at": "2024-11-01T00:00:00Z"
},
{
"url": "https://api.first.org/data/v1/epss?cve=CVE-2017-1000136",
"value": "0.00083",
"scoring_system": "epss",
"scoring_elements": "0.36853",
"published_at": "2024-11-18T00:00:00Z"
},
{
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000136",
"value": "4.3",
"scoring_system": "cvssv2",
"scoring_elements": "AV:N/AC:M/Au:N/C:N/I:P/A:N"
},
{
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000136",
"value": "6.5",
"scoring_system": "cvssv3",
"scoring_elements": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N"
}
],
"weaknesses": [
{
"cwe_id": "613",
"name": "Insufficient Session Expiration",
"description": "According to WASC, Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
}
],
"references": [
{
"url": "https://api.first.org/data/v1/epss?cve=CVE-2017-1000136",
"reference_type": "",
"reference_id": ""
},
{
"url": "https://bugs.launchpad.net/mahara/+bug/1363873",
"reference_type": "",
"reference_id": ""
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.10.0:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.10.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.10.0:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.10:rc1:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.10%3Arc1%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.10:rc1:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:15.04:rc1:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A15.04%3Arc1%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:15.04:rc1:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:15.04:rc2:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A15.04%3Arc2%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:15.04:rc2:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8.0:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8.0:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8.1:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8.1%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8.1:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8.2:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8.2%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8.2:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8.3:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8.3%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8.3:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8.4:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8.4%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8.4:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8.5:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8.5%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8.5:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8:rc1:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8%3Arc1%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8:rc1:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.8:rc2:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.8%3Arc2%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.8:rc2:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.9.0:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.9.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.9.0:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.9.1:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.9.1%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.9.1:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.9.2:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.9.2%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.9.2:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.9.3:*:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.9.3%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.9.3:*:*:*:*:*:*:*"
},
{
"url": "[https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:mahara:mahara:1.9:rc1:*:*:*:*:*:*](https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Aa%3Amahara%3Amahara%3A1.9%3Arc1%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A)",
"reference_type": "",
"reference_id": "cpe:2.3:a:mahara:mahara:1.9:rc1:*:*:*:*:*:*"
},
{
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000136",
"reference_type": "",
"reference_id": "CVE-2017-1000136"
}
]
}