CVE-2023-46052 is a high severity (CVSS 7.1) heap bounds overwrite in the test backend of SANE backends 1.2.1, triggered by a long init_mode string in a configuration file. The record marks it as disputed. No fixed version is named, so check your distribution advisory and avoid untrusted config files.
What's affected
The record names sane_backends 1.2.1. The NVD description says the overwrite is in init_options() in backend/test.c, caused by a long init_mode string in a config file. It also says the issue is disputed because nobody expects test.c to run with an attacker controlled configuration file.
The project issue we read describes a crash when the test device is opened with a crafted test.conf. The page we fetched did not show a maintainer reply, a dispute statement or a fixed version, so we cannot confirm one. No CWE is assigned in the record.
The NVD record scores it 7.1 (High) with the vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H. The record assigns no CWE. The record does not list this CVE in the CISA Known Exploited Vulnerabilities catalog, and nothing we read says it is exploited in the wild.
How to check if you're exposed
Check whether SANE is installed and which version:
scanimage -V
On Debian and Ubuntu style systems use dpkg -l libsane1 sane-utils. The test backend is a development aid and most scanning setups never enable it. Look in your SANE configuration directory, usually under /etc/sane.d, to see whether the test backend is listed in dll.conf and who can write to its config file.
What to do now
- Inventory machines with SANE installed, including print servers and desktop images.
- Make sure the test backend is not enabled on production hosts.
- Restrict write access to the SANE configuration files to administrators.
- Watch your distribution security tracker for a packaged update and apply it.
- Rescan images after patching so the finding is cleared.
Why it matters
A heap overwrite happens when a program copies data into a buffer without checking that it fits. In this report a string read from a config file is copied into a fixed size allocation. That can corrupt memory and crash the process, and in the worst case change how it behaves.
The dispute matters. If an attacker can already write the configuration of a debugging backend, they usually have other options. Even so, the sensible response is cheap: keep the test backend off and keep config files locked down.
Quick check
Why is this marked disputed?
The record says no one expects test.c to be run with a configuration file an attacker controls, so the real risk is limited to unusual setups.
Is there a fixed version?
We could not confirm one from the sources we read. Follow your distribution advisory.
Sources
Last reviewed: 19 October 2026.
