<?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-29T15:14:54.273943+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-19991</id>
    <title>fkie_cve-2026-19991</title>
    <updated>2026-09-29T15:14:56.136391+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>The UsersWP plugin for WordPress is vulnerable to Arbitrary File Deletion in versions up to, and including, 1.2.70 via the upload_file_remove() AJAX handler. The plugin stores the value of an account 'file' form field taken directly from $_POST when no real $_FILES upload is provided (process_account() calls uwp_validate_fields() and array_merges the result with the empty output of UsersWP_Files::validate_uploads()). At storage time the value is only checked with validate_file(), which passes any string that does not contain a literal '../'. When the value is later processed by upload_file_remove(), it is again gated with validate_file() and then normalized through uwp_get_file_relative_url(); that helper performs a global str_replace() of the uploads base URL against the stored URL, allowing a crafted URL containing embedded '..&lt;uploads-baseurl&gt;' tokens to collapse into '../../' traversal sequences after the last validation. The transformed value is then appended to the uploads base directory and passed to wp_delete_file() without any canonical containment check. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete arbitrary files on the affected site's server (including wp-config.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-19991"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-mw4c-2xg7-r9h8</id>
    <title>GHSA-mw4c-2xg7-r9h8</title>
    <updated>2026-09-29T15:14:56.136541+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>The UsersWP plugin for WordPress is vulnerable to Arbitrary File Deletion in versions up to, and including, 1.2.70 via the upload_file_remove() AJAX handler. The plugin stores the value of an account 'file' form field taken directly from $_POST when no real $_FILES upload is provided (process_account() calls uwp_validate_fields() and array_merges the result with the empty output of UsersWP_Files::validate_uploads()). At storage time the value is only checked with validate_file(), which passes any string that does not contain a literal '../'. When the value is later processed by upload_file_remove(), it is again gated with validate_file() and then normalized through uwp_get_file_relative_url(); that helper performs a global str_replace() of the uploads base URL against the stored URL, allowing a crafted URL containing embedded '..&lt;uploads-baseurl&gt;' tokens to collapse into '../../' traversal sequences after the last validation. The transformed value is then appended to the uploads base directory and passed to wp_delete_file() without any canonical containment check. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete arbitrary files on the affected site's server (including wp-config.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-mw4c-2xg7-r9h8"/>
  </entry>
</feed>
