CVE-2018-11761
published 2018-09-19CVE-2018-11761: In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability…
PriorityP343high7.5CVSS 3.0
AVNACLPRNUINSUCNINAH
EPSS
9.63%
94.9th percentile
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apache | tika | — | — |
| apache | tika | >= 0 < 1.20-1 | 1.20-1 |
| apache | tika | 0.1 – 1.18 | — |
| apache | tika | 0.1 – 1.19 | — |
| apache_software_foundation | apache_tika | — | — |
| debian | tika | < tika 1.20-1 (bullseye) | tika 1.20-1 (bullseye) |
| debian | tika | — | — |
| oracle | business_process_management_suite | — | — |
| oracle | business_process_management_suite | — | — |
CVSS provenance
nvdv3.07.5HIGHCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
nvdv2.05.0MEDIUMAV:N/AC:L/Au:N/C:N/I:N/A:P
ghsa7.5HIGH
osv7.5HIGH
vendor_apache7.5HIGH
vendor_debian7.5HIGH
vendor_redhat7.5HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
tika: Incomplete fix allows for XML entity expansion resulting in denial of service
vendor_redhat·2018-10-10·CVSS 7.5
CVE-2018-11796 [HIGH] CWE-776 tika: Incomplete fix allows for XML entity expansion resulting in denial of service
tika: Incomplete fix allows for XML entity expansion resulting in denial of service
In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML parsing. However, Tika reuses SAXParsers and calls reset() after each parse, which, for Xerces2 parsers, as per the documentation, removes the user-specified SecurityManager and thus removes entity expansion limits after the first parse. Apache Tika versions from 0.1 to 1.19 are therefore still vulnerable to entity expansions which can lead to a denial of service attack. Users should upgrade to 1.19.1 or later.
Statement: This issue affects the versions of tika which is embedded in the nutch package as shipped with Red Hat Satellite 5. The tika server is not exposed, as such exploitation is difficult, Red Hat Product Security
Red Hat
tika: XML entity expansion vulnerability due to lack of limit configuration
vendor_redhat·2018-09-19·CVSS 7.5
CVE-2018-11761 [HIGH] CWE-776 tika: XML entity expansion vulnerability due to lack of limit configuration
tika: XML entity expansion vulnerability due to lack of limit configuration
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
Statement: This issue affects the versions of tika which is embedded in the nutch package as shipped with Red Hat Satellite 5. The tika server is not exposed, as such exploitation is difficult, Red Hat Product Security has rated this issue as having security impact of Low. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Package: tika-core (Red Hat BPM Suite 6) - Will not fix
Package: came
Debian
CVE-2018-11796: tika - In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML...
vendor_debian·2018·CVSS 7.5
CVE-2018-11796 [HIGH] CVE-2018-11796: tika - In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML...
In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML parsing. However, Tika reuses SAXParsers and calls reset() after each parse, which, for Xerces2 parsers, as per the documentation, removes the user-specified SecurityManager and thus removes entity expansion limits after the first parse. Apache Tika versions from 0.1 to 1.19 are therefore still vulnerable to entity expansions which can lead to a denial of service attack. Users should upgrade to 1.19.1 or later.
Scope: local
bullseye: resolved
sid: resolved
Debian
CVE-2018-11761: tika - In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity ...
vendor_debian·2018·CVSS 7.5
CVE-2018-11761 [HIGH] CVE-2018-11761: tika - In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity ...
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
Scope: local
bullseye: resolved (fixed in 1.20-1)
sid: resolved (fixed in 1.20-1)
Apache
Apache tika: CVE-2018-11761
vendor_apache·CVSS 7.5
CVE-2018-11761 [HIGH] Apache tika: CVE-2018-11761
Apache tika: CVE-2018-11761
XML Entity Expansion Vulnerability Renfei (Brian) Wang 0.1-1.18
GHSA
High severity vulnerability that affects org.apache.tika:tika-core
ghsa·2018-10-17
CVE-2018-11761 [HIGH] CWE-611 High severity vulnerability that affects org.apache.tika:tika-core
High severity vulnerability that affects org.apache.tika:tika-core
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
OSV
Apache Tika is vulnerable to entity expansions which can lead to a denial of service attack
osv·2018-10-17·CVSS 7.5
CVE-2018-11796 [HIGH] Apache Tika is vulnerable to entity expansions which can lead to a denial of service attack
Apache Tika is vulnerable to entity expansions which can lead to a denial of service attack
In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML parsing. However, Tika reuses SAXParsers and calls reset() after each parse, which, for Xerces2 parsers, as per the documentation, removes the user-specified SecurityManager and thus removes entity expansion limits after the first parse. Apache Tika versions from 0.1 to 1.19 are therefore still vulnerable to entity expansions which can lead to a denial of service attack. Users should upgrade to 1.19.1 or later.
OSV
High severity vulnerability that affects org.apache.tika:tika-core
osv·2018-10-17
CVE-2018-11761 [HIGH] High severity vulnerability that affects org.apache.tika:tika-core
High severity vulnerability that affects org.apache.tika:tika-core
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
GHSA
Apache Tika is vulnerable to entity expansions which can lead to a denial of service attack
ghsa·2018-10-17·CVSS 7.5
CVE-2018-11796 [HIGH] CWE-611 Apache Tika is vulnerable to entity expansions which can lead to a denial of service attack
Apache Tika is vulnerable to entity expansions which can lead to a denial of service attack
In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML parsing. However, Tika reuses SAXParsers and calls reset() after each parse, which, for Xerces2 parsers, as per the documentation, removes the user-specified SecurityManager and thus removes entity expansion limits after the first parse. Apache Tika versions from 0.1 to 1.19 are therefore still vulnerable to entity expansions which can lead to a denial of service attack. Users should upgrade to 1.19.1 or later.
OSV
CVE-2018-11796: In Apache Tika 1
osv·2018-10-09·CVSS 7.5
CVE-2018-11796 [HIGH] CVE-2018-11796: In Apache Tika 1
In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML parsing. However, Tika reuses SAXParsers and calls reset() after each parse, which, for Xerces2 parsers, as per the documentation, removes the user-specified SecurityManager and thus removes entity expansion limits after the first parse. Apache Tika versions from 0.1 to 1.19 are therefore still vulnerable to entity expansions which can lead to a denial of service attack. Users should upgrade to 1.19.1 or later.
OSV
CVE-2018-11761: In Apache Tika 0
osv·2018-09-19·CVSS 7.5
CVE-2018-11761 [HIGH] CVE-2018-11761: In Apache Tika 0
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2018-11796 tika: Incomplete fix allows for XML entity expansion resulting in denial of service
bugzilla·2018-10-15·CVSS 7.5
CVE-2018-11796 [HIGH] CVE-2018-11796 tika: Incomplete fix allows for XML entity expansion resulting in denial of service
CVE-2018-11796 tika: Incomplete fix allows for XML entity expansion resulting in denial of service
Apache Tika 1.19 included an incomplete fix for CVE-2018-11761 which added an entity expansion limit for XML parsing. However, Tika reuses SAXParsers and calls reset() after each parse, which, for Xerces2 parsers, as per the documentation, removes the user-specified SecurityManager and thus removes entity expansion limits after the first parse. Apache Tika 1.19 is therefore still vulnerable to entity expansions which can lead to a denial of service attack.
External Reference:
https://lists.apache.org/thread.html/88de8350cda9b184888ec294c813c5bd8a2081de8fd3666f8904bc05@%3Cdev.tika.apache.org%3E
Upstream Issue:
https://issues.apache.org/jira/projects/TIKA/issues/TIKA-2727
Upstream Patc
Bugzilla
CVE-2018-11761 tika: XML entity expansion vulnerability due to lack of limit configuration [fedora-all]
bugzilla·2018-09-24·CVSS 7.5
CVE-2018-11761 [HIGH] CVE-2018-11761 tika: XML entity expansion vulnerability due to lack of limit configuration [fedora-all]
CVE-2018-11761 tika: XML entity expansion vulnerability due to lack of limit configuration [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects m
Bugzilla
CVE-2018-11761 tika: XML entity expansion vulnerability due to lack of limit configuration
bugzilla·2018-09-24·CVSS 7.5
CVE-2018-11761 [HIGH] CVE-2018-11761 tika: XML entity expansion vulnerability due to lack of limit configuration
CVE-2018-11761 tika: XML entity expansion vulnerability due to lack of limit configuration
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
References:
https://lists.apache.org/thread.html/5553e10bba5604117967466618f219c0cae710075819c70cfb3fb421@%3Cdev.tika.apache.org%3E
Discussion:
Created tika tracking bugs for this issue:
Affects: fedora-all [bug 1632463]
---
Upstream commit:
https://github.com/apache/tika/commit/bd9d75d8b0a85af2937047bfad04288c3044b2a6
Note that this commit would only apply cleanly to version 1.17 and later, which added XMLReaderUtils as part of the refactoring of XML parsers:
https://github.com/apache/ti
arXiv
How well does LLM generate security tests?
arxiv_fulltext·2023-10-03
How well does LLM generate security tests?
How well does LLM generate security tests?
## Abstract
Developers often build software on top of third-party libraries (Libs) to improve programmer productivity and software quality. The libraries may contain vulnerabilities exploitable by hackers to attack the applications (Apps) built on top of them. People refer to such attacks as supply chain attacks, the documented number of which has increased 742% in 2022. People created tools to mitigate such attacks, by scanning the library dependencies of Apps, identifying the usage of vulnerable library versions, and suggesting secure alternatives to vulnerable dependencies. However, recent studies show that many developers do not trust the reports by these tools; they ask for code or evidence to demonstrate how library vulnerabilities lead to
http://www.securityfocus.com/bid/105514https://lists.apache.org/thread.html/5553e10bba5604117967466618f219c0cae710075819c70cfb3fb421%40%3Cdev.tika.apache.org%3Ehttps://lists.apache.org/thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451%40%3Csolr-user.lucene.apache.org%3Ehttps://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.htmlhttp://www.securityfocus.com/bid/105514https://lists.apache.org/thread.html/5553e10bba5604117967466618f219c0cae710075819c70cfb3fb421%40%3Cdev.tika.apache.org%3Ehttps://lists.apache.org/thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451%40%3Csolr-user.lucene.apache.org%3Ehttps://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html
2018-09-19
Published