<?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-06T07:25:10.259155+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-280218</id>
    <title>EUVD-2026-280218</title>
    <updated>2026-10-06T07:25:10.318080+00:00</updated>
    <content>EUVD-2026-280218</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-280218"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-34973</id>
    <title>fkie_cve-2026-34973</title>
    <updated>2026-10-06T07:25:10.318122+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>phpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, the searchCustomPages() method in phpmyfaq/src/phpMyFAQ/Search.php uses real_escape_string() (via escape()) to sanitize the search term before embedding it in LIKE clauses. However, real_escape_string() does not escape SQL LIKE metacharacters % (match any sequence) and _ (match any single character). An unauthenticated attacker can inject these wildcards into search queries, causing them to match unintended records — including content that was not meant to be surfaced — resulting in information disclosure. This issue has been patched in version 4.1.1.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-34973"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-gcp9-5jc8-976x</id>
    <title>GHSA-gcp9-5jc8-976x — phpMyFAQ has a LIKE Wildcard Injection in Search.php — Unescaped % and _ Metacharacters Enable Broad Content Disclosure</title>
    <updated>2026-10-06T07:25:10.318162+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Packagist: thorsten/phpmyfaq</p>
<p>### Summary</p>
<p>The `searchCustomPages()` method in `phpmyfaq/src/phpMyFAQ/Search.php` uses `real_escape_string()` (via `escape()`) to sanitize the search term before embedding it in LIKE clauses. However, `real_escape_string()` does **not** escape SQL LIKE metacharacters `%` (match any sequence) and `_` (match any single character). An unauthenticated attacker can inject these wildcards into search queries, causing them to match unintended records — including content that was not meant to be surfaced — resulting in information disclosure.</p>
<p>### Details</p>
<p>**File:** `phpmyfaq/src/phpMyFAQ/Search.php`, lines 226–240</p>
<p>**Vulnerable code:**
```php
$escapedSearchTerm = $this-&gt;configuration-&gt;getDb()-&gt;escape($searchTerm);
$searchWords = explode(' ', $escapedSearchTerm);
$searchConditions = [];</p>
<p>foreach ($searchWords as $word) {
    if (strlen($word) &lt;= 2) {
        continue;
    }
    $searchConditions[] = sprintf(
        "(page_title LIKE '%%%s%%' OR content LIKE '%%%s%%')",
        $word,
        $word
    );
}
```</p>
<p>`escape()` calls `mysqli::real_escape_string()`, which escapes characters like `'`, `\`, `NULL`, etc. — but explicitly does **not** escape `%` or `_`, as these are not SQL string delimiters. They are, however, LIKE pattern wildcards.</p>
<p>**Attack vector:**</p>
<p>A user submits a search term containing `_` or `%` as part of a 3+ character word (to bypass the `strlen &lt;= 2` filter). Examples:</p>
<p>- Search for `a_b` → LIKE becomes `'%a_b%'` → `_` matches any single character, e.g. matche…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-gcp9-5jc8-976x"/>
  </entry>
</feed>
