<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T19:49:16.615120+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-57168</id>
    <title>fkie_cve-2026-57168</title>
    <updated>2026-09-29T19:49:16.616901+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2026-56120. Reason: This candidate is a duplicate of CVE-2026-56120. Notes: All CVE users should reference CVE-2026-56120 instead of this candidate.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-57168"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-h3m5-97jq-qjrf</id>
    <title>GHSA-h3m5-97jq-qjrf — OpenRemote Manager: removeAlarms cross-realm IDOR (bulk delete)</title>
    <updated>2026-09-29T19:49:16.616963+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: io.openremote:openremote-manager</p>
<p>### Summary
OpenRemote Manager is vulnerable to a cross-tenant Insecure Direct
Object Reference (IDOR) in the bulk alarm deletion endpoint. An
authenticated user in any realm can delete alarms belonging to other
realms (tenants) by supplying arbitrary alarm IDs. The vulnerability
exists because the bulk removeAlarms() method only verifies that the
caller's own realm is active and accessible, but never checks whether
the targeted alarm IDs belong to the caller's realm before deleting
them.</p>
<p>This allows any user with alarm write permissions in their own realm
to permanently destroy alarm records — including safety-critical and
security alerts — belonging to any other tenant on the same OpenRemote
installation.</p>
<p>------------------------------------------</p>
<p>[Additional Information]
The singular removeAlarm() method correctly validates that the
target alarm's realm matches the caller's access:</p>
<p>// CORRECT (singular):
    SentAlarm alarm = alarmService.getAlarm(alarmId);
    if (!isRealmActiveAndAccessible(alarm.getRealm())) {
        throw new ForbiddenException(...);
    }</p>
<p>The plural removeAlarms() method is missing this per-alarm realm
check and only validates the caller's own realm — a check that is
trivially satisfied for any authenticated user:</p>
<p>```
 // VULNERABLE (plural):
public void removeAlarms(RequestParams requestParams, List&lt;Long&gt; alarmIds) {
    if (!isRealmActiveAndAccessible(getAuthenticatedRealmName())) {  
        throw new ForbiddenException(...);  // always…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-h3m5-97jq-qjrf"/>
  </entry>
</feed>
