|
|
Search Results
There are 23 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2024-34399 | **UNSUPPORTED WHEN ASSIGNED** An issue was discovered in BMC Remedy Mid Tier 7.6.04. An unauthenticated remote attacker is able to access any user account without using any password. NOTE: This vulnerability only affects products that are no longer supported by the maintainer and the impacted version for this vulnerability is 7.6.04 only. |
| CVE-2024-24820 | Icinga Director is a tool designed to make Icinga 2 configuration handling easy. Not any of Icinga Director's configuration forms used to manipulate the monitoring environment are protected against cross site request forgery (CSRF). It enables attackers to perform changes in the monitoring environment managed by Icinga Director without the awareness of the victim. Users of the map module in version 1.x, should immediately upgrade to v2.0. The mentioned XSS vulnerabilities in Icinga Web are already fixed as well and upgrades to the most recent release of the 2.9, 2.10 or 2.11 branch must be performed if not done yet. Any later major release is also suitable. Icinga Director will receive minor updates to the 1.8, 1.9, 1.10 and 1.11 branches to remedy this issue. Upgrade immediately to a patched release. If that is not feasible, disable the director module for the time being. |
| CVE-2024-24819 | icingaweb2-module-incubator is a working project of bleeding edge Icinga Web 2 libraries. In affected versions the class `gipfl\Web\Form` is the base for various concrete form implementations [1] and provides protection against cross site request forgery (CSRF) by default. This is done by automatically adding an element with a CSRF token to any form, unless explicitly disabled, but even if enabled, the CSRF token (sent during a client's submission of a form relying on it) is not validated. This enables attackers to perform changes on behalf of a user which, unknowingly, interacts with a prepared link or website. The version 0.22.0 is available to remedy this issue. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| CVE-2024-21641 | Flarum is open source discussion platform software. Prior to version 1.8.5, the Flarum `/logout` route includes a redirect parameter that allows any third party to redirect users from a (trusted) domain of the Flarum installation to redirect to any link. For logged-in users, the logout must be confirmed. Guests are immediately redirected. This could be used by spammers to redirect to a web address using a trusted domain of a running Flarum installation. The vulnerability has been fixed and published as flarum/core v1.8.5. As a workaround, some extensions modifying the logout route can remedy this issue if their implementation is safe. |
| CVE-2023-52828 | In the Linux kernel, the following vulnerability has been resolved: bpf: Detect IP == ksym.end as part of BPF program Now that bpf_throw kfunc is the first such call instruction that has noreturn semantics within the verifier, this also kicks in dead code elimination in unprecedented ways. For one, any instruction following a bpf_throw call will never be marked as seen. Moreover, if a callchain ends up throwing, any instructions after the call instruction to the eventually throwing subprog in callers will also never be marked as seen. The tempting way to fix this would be to emit extra 'int3' instructions which bump the jited_len of a program, and ensure that during runtime when a program throws, we can discover its boundaries even if the call instruction to bpf_throw (or to subprogs that always throw) is emitted as the final instruction in the program. An example of such a program would be this: do_something(): ... r0 = 0 exit foo(): r1 = 0 call bpf_throw r0 = 0 exit bar(cond): if r1 != 0 goto pc+2 call do_something exit call foo r0 = 0 // Never seen by verifier exit // main(ctx): r1 = ... call bar r0 = 0 exit Here, if we do end up throwing, the stacktrace would be the following: bpf_throw foo bar main In bar, the final instruction emitted will be the call to foo, as such, the return address will be the subsequent instruction (which the JIT emits as int3 on x86). This will end up lying outside the jited_len of the program, thus, when unwinding, we will fail to discover the return address as belonging to any program and end up in a panic due to the unreliable stack unwinding of BPF programs that we never expect. To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as part of the BPF program, so that is_bpf_text_address returns true when such a case occurs, and we are able to unwind reliably when the final instruction ends up being a call instruction. |
| CVE-2023-39913 | Deserialization of Untrusted Data, Improper Input Validation vulnerability in Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK.This issue affects Apache UIMA Java SDK: before 3.5.0. Users are recommended to upgrade to version 3.5.0, which fixes the issue. There are several locations in the code where serialized Java objects are deserialized without verifying the data. This affects in particular: * the deserialization of a Java-serialized CAS, but also other binary CAS formats that include TSI information using the CasIOUtils class; * the CAS Editor Eclipse plugin which uses the the CasIOUtils class to load data; * the deserialization of a Java-serialized CAS of the Vinci Analysis Engine service which can receive using Java-serialized CAS objects over network connections; * the CasAnnotationViewerApplet and the CasTreeViewerApplet; * the checkpointing feature of the CPE module. Note that the UIMA framework by default does not start any remotely accessible services (i.e. Vinci) that would be vulnerable to this issue. A user or developer would need to make an active choice to start such a service. However, users or developers may use the CasIOUtils in their own applications and services to parse serialized CAS data. They are affected by this issue unless they ensure that the data passed to CasIOUtils is not a serialized Java object. When using Vinci or using CasIOUtils in own services/applications, the unrestricted deserialization of Java-serialized CAS files may allow arbitrary (remote) code execution. As a remedy, it is possible to set up a global or context-specific ObjectInputFilter (cf. https://openjdk.org/jeps/290 and https://openjdk.org/jeps/415 ) if running UIMA on a Java version that supports it. Note that Java 1.8 does not support the ObjectInputFilter, so there is no remedy when running on this out-of-support platform. An upgrade to a recent Java version is strongly recommended if you need to secure an UIMA version that is affected by this issue. To mitigate the issue on a Java 9+ platform, you can configure a filter pattern through the "jdk.serialFilter" system property using a semicolon as a separator: To allow deserializing Java-serialized binary CASes, add the classes: * org.apache.uima.cas.impl.CASCompleteSerializer * org.apache.uima.cas.impl.CASMgrSerializer * org.apache.uima.cas.impl.CASSerializer * java.lang.String To allow deserializing CPE Checkpoint data, add the following classes (and any custom classes your application uses to store its checkpoints): * org.apache.uima.collection.impl.cpm.CheckpointData * org.apache.uima.util.ProcessTrace * org.apache.uima.util.impl.ProcessTrace_impl * org.apache.uima.collection.base_cpm.SynchPoint Make sure to use "!*" as the final component to the filter pattern to disallow deserialization of any classes not listed in the pattern. Apache UIMA 3.5.0 uses tightly scoped ObjectInputFilters when reading Java-serialized data depending on the type of data being expected. Configuring a global filter is not necessary with this version. |
| CVE-2023-28104 | `silverstripe/graphql` serves Silverstripe data as GraphQL representations. In versions 4.2.2 and 4.1.1, an attacker could use a specially crafted graphql query to execute a denial of service attack against a website which has a publicly exposed graphql endpoint. This mostly affects websites with particularly large/complex graphql schemas. Users should upgrade to `silverstripe/graphql` 4.2.3 or 4.1.2 to remedy the vulnerability. |
| CVE-2022-26088 | An issue was discovered in BMC Remedy before 22.1. Email-based Incident Forwarding allows remote authenticated users to inject HTML (such as an SSRF payload) into the Activity Log by placing it in the To: field. This affects rendering that occurs upon a click in the "number of recipients" field. NOTE: the vendor's position is that "no real impact is demonstrated." |
| CVE-2020-25667 | TIFFGetProfiles() in /coders/tiff.c calls strstr() which causes a large out-of-bounds read when it searches for `"dc:format=\"image/dng\"` within `profile` due to improper string handling, when a crafted input file is provided to ImageMagick. The patch uses a StringInfo type instead of a raw C string to remedy this. This could cause an impact to availability of the application. This flaw affects ImageMagick versions prior to 7.0.9-0. |
| CVE-2019-16755 | BMC Remedy ITSM Suite is prone to unspecified vulnerabilities in both DWP and SmartIT components, which can permit remote attackers to perform pre-authenticated remote commands execution on the Operating System running the targeted application. Affected DWP versions: versions: 3.x to 18.x, all versions, service packs, and patches are affected by this vulnerability. Affected SmartIT versions: 1.x, 2.0, 18.05, 18.08, and 19.02, all versions, service packs, and patches are affected by this vulnerability. |
| CVE-2018-19505 | Remedy AR System Server in BMC Remedy 7.1 may fail to set the correct user context in certain impersonation scenarios, which can allow a user to act with the identity of a different user, because userdata.js in the WOI:WorkOrderConsole component allows a username substitution involving a UserData_Init call. |
| CVE-2018-18862 | BMC Remedy Mid-Tier 7.1.00 and 9.1.02.003 for BMC Remedy AR System has Incorrect Access Control in ITAM forms, as demonstrated by TLS%3APLR-Configuration+Details/Default+Admin+View/, AST%3AARServerConnection/Default+Admin+View/, and AR+System+Administration%3A+Server+Information/Default+Admin+View/. |
| CVE-2017-18228 | Remedy Mid Tier in BMC Remedy AR System 9.1 allows XSS via the ATTKey parameter in an arsys/servlet/AttachServlet request. |
| CVE-2017-18223 | BMC Remedy AR System before 9.1 SP3, when Remedy AR Authentication is enabled, allows attackers to obtain administrative access. |
| CVE-2017-17678 | BMC Remedy Mid Tier 9.1SP3 is affected by cross-site scripting (XSS). A DOM-based cross-site scripting vulnerability was discovered in a legacy utility. |
| CVE-2017-17677 | BMC Remedy 9.1SP3 is affected by authenticated code execution. Authenticated users that have the right to create reports can use BIRT templates to run code. |
| CVE-2017-17675 | BMC Remedy Mid Tier 9.1SP3 is affected by log hijacking. Remote logging can be accessed by unauthenticated users, allowing for an attacker to hijack the system logs. This data can include user names and HTTP data. |
| CVE-2017-17674 | BMC Remedy Mid Tier 9.1SP3 is affected by remote and local file inclusion. Due to the lack of restrictions on what can be targeted, the system can be vulnerable to attacks such as system fingerprinting, internal port scanning, Server Side Request Forgery (SSRF), or remote code execution (RCE). |
| CVE-2016-2349 | Remedy AR System Server in BMC Remedy 8.1 SP 2, 9.0, 9.0 SP 1, and 9.1 allows attackers to reset arbitrary passwords via a blank previous password. |
| CVE-2015-9257 | BMC Remedy Action Request (AR) System 9.0 before 9.0.00 Service Pack 2 hot fix 1 has persistent XSS. |
| CVE-2015-5072 | The BIRT Engine servlet in the AR System Mid Tier component before 9.0 SP1 for BMC Remedy AR System Server allows remote authenticated users to "navigate" to arbitrary local files via the __imageid parameter. |
| CVE-2015-5071 | AR System Mid Tier in the AR System Mid Tier component before 9.0 SP1 for BMC Remedy AR System Server allows remote authenticated users to "navigate" to arbitrary files via the __report parameter of the BIRT viewer servlet. |
| CVE-2007-0310 | BMC Remedy Action Request System 5.01.02 Patch 1267 generates different error messages for failed login attempts with a valid username than for those with an invalid username, which allows remote attackers to determine valid account names. |
|
You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select “Other” from dropdown)
|
||
