https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 07:36:11 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-243719 EUVD-2026-243719 https://cve.radiocsirt.org/vuln/euvd-2026-243719 https://cve.radiocsirt.org/vuln/fkie_cve-2025-49143 <p>Nautobot is a Network Source of Truth and Network Automation Platform. Prior to v2.4.10 and v1.6.32 , files uploaded by users to Nautobot&#39;s MEDIA_ROOT directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file. Nautobot v2.4.10 and v1.6.32 address this issue by adding enforcement of Nautobot user authentication to this endpoint.</p> <p>Nautobot is a Network Source of Truth and Network Automation Platform. Prior to v2.4.10 and v1.6.32 , files uploaded by users to Nautobot&#39;s MEDIA_ROOT directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file. Nautobot v2.4.10 and v1.6.32 address this issue by adding enforcement of Nautobot user authentication to this endpoint.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-49143 https://cve.radiocsirt.org/vuln/ghsa-rh67-4c8j-hjjh <p><strong>Affected:</strong> PyPI: nautobot</p> <p>### Impact</p> <p>Files uploaded by users to Nautobot&#39;s `MEDIA_ROOT` directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.</p> <p>For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the `devicetype-images/` subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.</p> <p>Similarly, for all other image attachments, while the images *can* be listed by accessing the `/api/extras/image-attachments/` endpoint *as an authenticated user only*, absent that authenticated access, accessing the files would again require guessing file names correctly.</p> <p>### Patches</p> <p>Nautobot v2.4.10 and v1.6.32 will address this issue by adding enforcement of Nautobot user authentication to this endpoint.</p> <p>### Workarounds</p> <p>No workaround other than applying the patch given in https://github.com/nautobot/nautobot/pull/6672 (2.x) or https://github.com/nautobot/nautobot/pull/6703 (1.6)</p> <p>### References _Are there any links users can visit to find out more?_</p> <p>- https://github.com/nautobot/nautobot/commit/9c892dc300429948a4714f743c9c2879d8987340 - https://github.com/nautobot/nautobot/commit/d99a53b0651…</p> <p><strong>Affected:</strong> PyPI: nautobot</p> <p>### Impact</p> <p>Files uploaded by users to Nautobot&#39;s `MEDIA_ROOT` directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.</p> <p>For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the `devicetype-images/` subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.</p> <p>Similarly, for all other image attachments, while the images *can* be listed by accessing the `/api/extras/image-attachments/` endpoint *as an authenticated user only*, absent that authenticated access, accessing the files would again require guessing file names correctly.</p> <p>### Patches</p> <p>Nautobot v2.4.10 and v1.6.32 will address this issue by adding enforcement of Nautobot user authentication to this endpoint.</p> <p>### Workarounds</p> <p>No workaround other than applying the patch given in https://github.com/nautobot/nautobot/pull/6672 (2.x) or https://github.com/nautobot/nautobot/pull/6703 (1.6)</p> <p>### References _Are there any links users can visit to find out more?_</p> <p>- https://github.com/nautobot/nautobot/commit/9c892dc300429948a4714f743c9c2879d8987340 - https://github.com/nautobot/nautobot/commit/d99a53b0651…</p> https://cve.radiocsirt.org/vuln/ghsa-rh67-4c8j-hjjh https://cve.radiocsirt.org/vuln/pysec-2026-1689 <p><strong>Affected:</strong> PyPI: nautobot</p> <p>### Impact</p> <p>Files uploaded by users to Nautobot&#39;s `MEDIA_ROOT` directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.</p> <p>For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the `devicetype-images/` subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.</p> <p>Similarly, for all other image attachments, while the images *can* be listed by accessing the `/api/extras/image-attachments/` endpoint *as an authenticated user only*, absent that authenticated access, accessing the files would again require guessing file names correctly.</p> <p>### Patches</p> <p>Nautobot v2.4.10 and v1.6.32 will address this issue by adding enforcement of Nautobot user authentication to this endpoint.</p> <p>### Workarounds</p> <p>No workaround other than applying the patch given in https://github.com/nautobot/nautobot/pull/6672 (2.x) or https://github.com/nautobot/nautobot/pull/6703 (1.6)</p> <p>### References _Are there any links users can visit to find out more?_</p> <p>- https://github.com/nautobot/nautobot/commit/9c892dc300429948a4714f743c9c2879d8987340 - https://github.com/nautobot/nautobot/commit/d99a53b0651…</p> <p><strong>Affected:</strong> PyPI: nautobot</p> <p>### Impact</p> <p>Files uploaded by users to Nautobot&#39;s `MEDIA_ROOT` directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.</p> <p>For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the `devicetype-images/` subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.</p> <p>Similarly, for all other image attachments, while the images *can* be listed by accessing the `/api/extras/image-attachments/` endpoint *as an authenticated user only*, absent that authenticated access, accessing the files would again require guessing file names correctly.</p> <p>### Patches</p> <p>Nautobot v2.4.10 and v1.6.32 will address this issue by adding enforcement of Nautobot user authentication to this endpoint.</p> <p>### Workarounds</p> <p>No workaround other than applying the patch given in https://github.com/nautobot/nautobot/pull/6672 (2.x) or https://github.com/nautobot/nautobot/pull/6703 (1.6)</p> <p>### References _Are there any links users can visit to find out more?_</p> <p>- https://github.com/nautobot/nautobot/commit/9c892dc300429948a4714f743c9c2879d8987340 - https://github.com/nautobot/nautobot/commit/d99a53b0651…</p> https://cve.radiocsirt.org/vuln/pysec-2026-1689