Security improvements
Image viewers process files from many different sources, including potentially malicious files.
I would implement the following ( I didnt looked at your code , just an idea! :
Decoder isolation: execute risky decoders in restricted subprocesses.
Memory safety: use bounds-checked operations and safer C++ practices.
Resource limits: limit memory, image dimensions, decompression ratios and processing time.
Input validation: validate image structures before processing.
Dependency updates: regularly update bundled codec libraries.
Signed plugins: verify plugin signatures and hashes.
Fuzz testing: test image decoders with malformed and unusual files.
Sandboxing: use Linux security mechanisms such as seccomp and filesystem restrictions for isolated workers.
I would also enable AddressSanitizer and UndefinedBehaviorSanitizer in development and testing builds.
2.
Hardware acceleration
Consider GPU acceleration for operations where it actually helps:
Image scaling.
Rotation.
Color conversion.
Display rendering.
Some image filters.
B)
My priority list would be:
----------------------------------
1
Plugin manager redesign
Much better reliability
2
Background thumbnail engine
Faster browsing
3
Better caching
Faster startup and navigation
4
Decoder isolation
Better security
5
Modern dependency management
Fewer Linux compatibility problems
6
GPU acceleration
Faster display and selected operations
7
Database optimization
Better large collections
I would benchmark each change before and after implementation, especially with directories containing 10,000–100,000 images.
Replace plugin system
C )
Worth investigating
--------------------------
- Add plugin diagnostics
- Isolate image decoders
- ( Introduce SQLite WAL - Benchmark first )
-Load visible thumbnails first, then nearby thumbnails, and only afterwards the rest.
This would make browsing large folders more responsive.
- Cache performance
Investigate the size and access patterns of Thumb.db, database locking and the cost of rebuilding thumbnails.
- ( Profile slow SQL queries :
-Examine missing indexes
-Batch database writes
-Reduce unnecessary transactions
-Optimize thumbnail BLOB access
-Test database performance on SSD and HDD
)
D)
WAL can improve concurrent reading while writing. However, it introduces additional considerations:
Checkpoint management.
Additional WAL files.
Network filesystem compatibility.
Database backup consistency.
Concurrent writer behavior.
E) Security: where improvements really make sense
-----------------------------------------------------------------------
Update bundled image codecs
Fuzz-test image decoders
Check image dimensions and memory requirements
Fix buffer overflows and integer overflows
Apply security patches promptly
Isolate complex decoders in subprocesses
Verify downloaded update packages
Sign third-party plugins
F)
One consistent Linux release process
DEB: verify all declared dependencies.
RPM: verify Fedora and openSUSE compatibility.
AppImage: test bundled Qt libraries and plugin paths.
Flatpak: verify runtime compatibility and filesystem permissions.
TGZ: provide a dependency checker and startup diagnostics.
Automated release testing
Test startup, image decoding, thumbnail generation, metadata editing and plugin loading on clean virtual machines.
G)
I would not simply tell Debian users to install libxcb-cursor0.
Instead :
Identify which Qt platform plugin actually requires the library.
Declare the correct runtime dependency in the DEB package.
Test on Debian 12 and 13.
Provide a useful diagnostic if a dependency is missing.
Avoid bundling incompatible system libraries unnecessarily.
That will help determine whether this is a genuine XnView packaging problem or simply a missing dependency on your installation.
H) Examples
Real security vulnerabilities in image codecs
WebP – CVE-2023-4863
HEIF / AVIF – libheif, 2026
RAW – LibRaw, CVE-2025-43961 to 43964
TIFF – CVE-2026-46604
I)
What I would change in XnView MP
My strongest recommendations:
Security measure
Importance
Keep all codec libraries updated
Critical
Audit bundled .so libraries
Critical
Fuzz-test image decoders
Critical
Check image dimensions and memory allocation
High
Isolate complex codecs in separate processes
High
Restrict decoder filesystem access
High
Verify plugin authenticity
High
Monitor dependencies for known CVEs
High
J)
Particularly important: plugin isolation
I would change XnView so that complex and less frequently used decoders can run in restricted subprocesses.
For example:
JPEG, PNG: trusted, regularly updated decoding path.
RAW: isolated decoder worker.
HEIF/AVIF: isolated decoder worker.
Third-party plugins: isolated by default.
On Linux, technologies such as seccomp, namespaces and filesystem restrictions can help implement this.
A decoder should ideally have access only to:
The image file it needs to read.
Its own temporary working directory.
A controlled communication channel back to XnView.
It should not need unrestricted access to the user's home directory.
K)
One more problem: malicious plugins themselves
There is another risk independent of image vulnerabilities.
A malicious or compromised plugin can contain ordinary executable code.
For example, a plugin could:
Read files from the user's home directory.
Access browser profile data.
Modify documents.
Establish network connections.
Install persistent user-level components.
This is why simply checking whether a plugin is technically compatible is insufficient.
XnView should distinguish between:
Official plugins.
Verified third-party plugins.
Unknown plugins.
Incompatible or outdated plugins.
L)
My recommendation: a Linux security audit for XnView
I would actually start with an inventory before changing the architecture.
For every bundled library and plugin, record:
Information
Example
Library : libheif
Version : 1.23.1
Origin : Bundled / system
Security status : Vulnerable / patched / unknown
Dependencies : Other .so libraries
Update status : Current / outdated
This would allow the developer to identify outdated components without unnecessarily replacing the entire application.
My most important recommendation: XnView should have an automated security check for every image codec and plugin included in each release.
One vulnerable RAW, HEIF or WebP decoder can undermine the security of the entire image viewer.
And I would make decoder isolation a major feature of the next Linux release, not just another optional security setting.
GOOD LUCK !
Linux general + Security Improvements
Moderator: xnview