Oracle Retail Xstore Payment 3.3
Approved changes feed: RSS · Atom
cpe:2.3:a:oracle:retail_xstore_payment:3.3:*:*:*:*:*:*:*
part: a version: 3.3 update: *
| Vendor | Oracle (3509f9eb-d8a0-57da-b153-b8021021b133) |
|---|---|
| Product | Retail Xstore Payment (f5e20487-fc4e-5b12-9149-0137bf0390b1) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from NVD CPE 2.0 feed |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2018-3311 |
vulnerable | 2026-06-08 05:11:38.976068 |
Details available
Vulnerability in the Oracle Retail Xstore Payment component of Oracle Retail Applications (subcomponent: Security). The supported version that is affected is 3.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Retail Xstore Payment. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Retail Xstore Payment accessible data as well as unauthorized update, insert or delete access to some of Oracle Retail Xstore Payment accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Retail Xstore Payment. CVSS 3.0 Base Score 8.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L).
Published: 2019-01-16T19:00:00.000Z
Updated: 2024-10-02T16:24:56.339Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2017-7658 |
vulnerable | 2026-06-08 05:10:05.691524 |
Details available
In Eclipse Jetty Server, versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization.
Published: 2018-06-26T17:00:00.000Z
Updated: 2024-08-05T16:12:27.826Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.