<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-06T02:28:52.566066+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/euvd-2026-349389</id>
    <title>EUVD-2026-349389</title>
    <updated>2026-10-06T02:28:52.600352+00:00</updated>
    <content>EUVD-2026-349389</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-349389"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-48080</id>
    <title>fkie_cve-2026-48080</title>
    <updated>2026-10-06T02:28:52.600392+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, the `GET /api/tenants/{id}` endpoint returns the full tenant record to any authenticated `TENANT_ADMIN` of that tenant, including the `databaseUrl` field. This field contains the live PostgreSQL connection string the application uses to connect to that tenant's database. In the tested official `docker-compose.prod.yml` deployment, the connection string contained the user `postgres` with `rolsuper=true` and the plaintext password from `secrets/postgres_password.txt`. Operators who configure a non-superuser PostgreSQL user via `secrets/postgres_user.txt` would expose a less privileged credential, but the disclosure of the connection string itself is independent of that choice. The same credential applies to every database managed by that PostgreSQL instance: the central `appointment_booking` database, every per-tenant database (one per tenant), and the postgres administrative database. A `TENANT_ADMIN` of one tenant who can reach `postgres:5432` (directly via internal network, indirectly via any SSRF, RCE, or file-read in the application) can read every other tenant's appointment ciphertexts, key shares, and metadata; read the central user table, including all `GLOBAL_ADMIN` accounts, password hashes, and session records; modify or delete any data in any tenant database; and/or i a superuser-scoped deployment: use PostgreSQL's `pg_read_server_file…</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-48080"/>
  </entry>
</feed>
