WoluTools

Security and processing

Clear file handling, without vague security claims.

WoluTools explains what is tested, where each worker runs and which protections must be complete before public customer files are accepted.

Latest platform verification: 30 August 2026Public demos, closed app states and server workflows were checked on the production stack. Synthetic test jobs and files were removed afterwards.

Current processing model

Price List Compare is a server-side workflow. Files do leave the browser when a comparison is submitted. Processing runs on infrastructure controlled for WoluTools; files are not sent to an external AI provider.

Deletion lifecycle

  1. The old and new file are received for the selected comparison.
  2. The worker reads the chosen SKU and price columns and creates the result.
  3. Original uploads are deleted after processing.
  4. Result download access ends exactly seven days after creation.
  5. Generated files are physically removed in the next cleanup cycle, which runs at least every five minutes and retries deletion failures.

Validation already tested

  • CSV and XLSX structure validation with archive and component limits
  • 10 MB current per-file limit and 100,000-row capacity test per file
  • strict German and English price parsing with commercial two-decimal rounding
  • atomic duplicate-job protection
  • formula-injection protection for data, source filenames and worksheet names
  • controlled public errors without internal paths or library details
  • desktop and 360-pixel mobile result flow

How account uploads are protected

Verified accounts own their jobs and downloads. Files are processed only for the selected tool, protected according to the documented workflow and removed on the stated retention schedule. Prepared marketing examples do not accept customer files.

Responsible reporting

Security concerns can be reported to info@wolutools.com. Do not include passwords, private keys or real customer files in an initial report.

Isolated image processing

The Product Image Batch Editor, Target Size Image Compressor and YouTube Thumbnail Editor use a dedicated image worker and Redis queue. Only one image job runs at a time. The worker is limited to three CPU cores and 4 GiB RAM, runs as an unprivileged user in a read-only container and has no public internet route.

  • Static JPG, PNG, WebP and AVIF only
  • extension, MIME type, magic bytes, dimensions and animation checks
  • 12,000 pixels per side and 40 megapixels per image
  • one thumbnail background plus one optional foreground
  • safe UUID storage names, ZIP entries and SHA-256 artifact inventories
  • controlled errors without library or storage paths
  • thumbnail exports counted only after package verification
  • originals deleted after success or failure
  • previews and ZIP results blocked after 24 hours and removed in the next cleanup cycle

The image worker uses libvips and Pillow without an external AI or image API. The Price Compare worker keeps its own queue and cannot be occupied by image jobs.

Isolated e-invoice validation

The e-invoice worker has database, queue and encrypted-storage access but no public internet route. Official validator artifacts are pinned by version and SHA-256 during the image build. Runtime XML parsing blocks DTDs and external entities; cleartext documents exist only in a restricted temporary filesystem while the report is created.

  • KoSIT Validator 1.6.2 with pinned XRechnung and Peppol configurations
  • Mustangproject 2.26.0 for ZUGFeRD 2.5.2, Factur-X 1.09.2 and CEN EN 16931 1.3.16
  • content-based XML/PDF checks and bounded document sizes
  • encrypted sources, findings, repair choices and ZIP results
  • signed documents cannot be repaired
  • 24-hour source and result expiry plus immediate user deletion

Isolated document comparison

The document-compare worker has database, queue and encrypted-storage access but no public internet route. PDF, DOCX and TXT files are processed locally in a restrictive temporary filesystem. OOXML path traversal, unsafe expansion, macros, embedded objects and external relationships are blocked before extraction.

  • exactly two bounded source files and original SHA-256 binding
  • local PDF extraction and Tesseract OCR
  • deterministic versioned alignment with uncertain matches separated
  • HTML escaping and spreadsheet-formula protection
  • encrypted sources, structures, alignment choices and ZIP results
  • 24-hour expiry plus immediate user deletion

Isolated secure PDF redaction

The PDF-redaction worker has database, queue and encrypted-storage access but no public internet route. It renders and OCRs pages locally, applies only confirmed rectangles, strips hidden data, performs a complete qpdf rewrite and independently reopens the output for leak checks.

  • one bounded PDF and source SHA-256 binding
  • XChaCha20-Poly1305 for source, previews, selections and results
  • no visual-overlay-only redaction
  • metadata, attachments, comments, forms and JavaScript removed
  • confirmed values and incremental history checked after rewrite
  • two-hour drafts, immediate source cleanup and 24-hour results

Isolated PDF accessibility preflight

The PDF-accessibility worker has database, queue and encrypted-storage access but no public internet route. It runs pinned veraPDF and local deterministic inspection in a restrictive temporary filesystem, then revalidates any separately created guided-fixed copy.

  • one bounded PDF and source SHA-256 binding
  • XChaCha20-Poly1305 for source, previews, choices and results
  • pinned veraPDF 1.30.2 and versioned scoring
  • no invented tag trees, reading order, table semantics or alternative text
  • signed files remain report-only
  • two-hour drafts, immediate source cleanup and 24-hour results

Bounded thumbnail rendering

The existing image worker renders thumbnail packages locally with pinned fonts and versioned SVG-derived layouts. It has no need to contact YouTube, a font service, an image model or another design API.

  • one content-checked image with 20 MB, 40-megapixel and 12,000-pixel limits
  • animation and damaged-image rejection plus EXIF orientation handling
  • escaped text and a fixed server-side font set
  • separate confirmed crops for video and Shorts artwork
  • metadata removal and deterministic output manifests
  • two-hour drafts, immediate source cleanup and 24-hour results

Local loudness measurement and media processing

The internetless creator worker uses pinned FFmpeg and FFprobe builds for complete primary-audio-stream measurement, private previews and confirmed two-pass processing. The upload API stores only encrypted 32 MB chunks with content-checked container signatures.

  • one owned source, one active package and bounded duration and byte limits
  • XChaCha20-Poly1305 encrypted chunks, previews, reports and fixed media
  • confirmed source and settings hash before a package job can start
  • video stream copy for the supported MP4 path and independently measured output audio
  • no YouTube credentials, network publishing, AI or external mastering API
  • two-hour source and preview lifecycle plus 24-hour encrypted results

Local caption parsing and bounded timing review

The internetless creator worker parses captions and uses pinned FFmpeg and FFprobe only when optional media is supplied. Media comparison detects silence boundaries; it performs no speech recognition and receives no YouTube credentials.

  • one content-checked caption source, optional media and one active package
  • XChaCha20-Poly1305 encrypted 32 MB parts, findings, choices and results
  • confirmed source and settings hash before a package job can start
  • bounded offset and drift suggestions that always require listening and confirmation
  • formula-protected CSV, escaped HTML and verified ZIP paths
  • two-hour source and analysis lifecycle plus 24-hour encrypted results

Streaming CSV validation

The existing data worker reads bounded CSV and TSV inputs as a stream and creates reports locally. It never connects to a spreadsheet platform, data broker or AI service, and it does not guess structurally ambiguous rows.

  • 50 MB, 100,000-row, 250-column and one-megabyte-field limits
  • strict RFC-style quoting, encoding and consistent-column checks
  • safe bounded regular-expression rules without backreferences or nested quantifiers
  • separate value-preserving and risk-reduced spreadsheet review exports; no universal formula-safety claim
  • source SHA-256 recheck plus exact artifact byte and hash inventory verified before completion
  • jobs counted only after the package passes verification
  • two-hour drafts, immediate source cleanup and 24-hour results

Merchant feed processing

Product feeds run in a separate data-worker queue with no public internet access. Filenames are not used as storage paths or shell input. Archive, file-size, row and column limits are checked before processing; spreadsheet cells and CSV exports are protected against formula execution. Original feeds are deleted after processing and result downloads expire after 24 hours.

Rental-data processing

Rental fields and source documents use versioned application-level encryption. The dedicated rental worker has no public internet access, runs as an unprivileged read-only container with bounded CPU, memory and temporary storage, and processes one rental job at a time. OCR is local and uncertain fields are not guessed.

Final calculations store an immutable encrypted input snapshot, result, trace, country ruleset version and code hash. Package downloads expire after 24 hours. The real-data gate stays closed until independent country review, processor terms, external encrypted backup and the complete security acceptance are finished.