Corporate Nextcloud Security Gaps: Default Settings, Antivirus Failures and Open Source Integration Challenges
Nextcloud in corporate environments demands far more than default open source settings to achieve acceptable security levels, according to a detailed technical review published by K2Tech.
The company’s specialist Roma Masyagutov explains that while LDAP integration, antivirus plugins, audit logging and access policies exist, real-world testing often exposes dangerous gaps. A large infected file can still reach storage even when an antivirus solution is supposedly active.
Architecture and Perimeter Defenses
Corporate Nextcloud runs across load balancers, application servers, a MariaDB Galera cluster for metadata, Redis for sessions, S3 object storage and Elasticsearch for logs, all spread across three availability zones. WAF solutions from vendors such as Wallarm and Qrator plus Anti-DDoS services sit in front of the infrastructure. Additional layers include vulnerability scanning with VULS, infrastructure-level SRK, security groups, IAM and CloudTrail logging.
LDAP and Antivirus Integration Issues
Native LDAP plugins connect reliably to corporate Active Directory, automatically mapping groups and permissions. Antivirus integration, however, proves far more fragile. When the antivirus service becomes unreachable, the Antivirus for files plugin simply uploads the file to S3 without scanning. A later parameter avBlockUnreachable was added, yet it functions only with ClamAV and still requires manual configuration for other engines.
Another critical flaw appears during chunked uploads. Files are transferred in 5–10 MB pieces and reassembled with a MOVE command. Older plugin versions checked only individual PUT requests, leaving the final assembled file unexamined. Administrators must update the plugin and align chunk sizes with the antivirus stream length using commands such as occ config:app:set files max_chunk_size --value="104857600".
Comparing Three Antivirus Engines
Three ICAP-based engines were evaluated on identical hardware: ClamAV, Kaspersky Scan Engine and PT Sandbox.
- ClamAV offers open source signature-based detection but lacks built-in clustering, web panels and monitoring; administrators must build these capabilities themselves.
- Kaspersky Scan Engine provides a web console, native clustering via shared database and integration with SIEM systems, delivering the fastest inline scanning speeds in tests.
- PT Sandbox combines signature detection with behavioral analysis yet proved the most resource-intensive, with load averages reaching 115 during sequential uploads.
Throughput measurements for 30 MB and 100 MB files containing EICAR signatures showed Kaspersky Scan Engine consistently outperforming the others, while PT Sandbox imposed the highest CPU overhead even without behavioral analysis enabled.
The authors conclude that antivirus scanning in a Nextcloud pipeline must be treated as a dedicated service whose failure modes, monitoring, high-availability design and re-scan policies require careful engineering. Frequent Nextcloud releases and plugin updates further necessitate ongoing regression testing on staging environments before production rollout.
Related articles
Unicode Tricks Let Malicious Python Code Bypass Code Review
A detailed analysis shows how subtle Unicode manipulations allow code to pass human review while executing entirely different logic. The first technique replaces Latin characters with visually identical Cyrillic or other script letters inside identifiers, such as using Ukrainian 'і' instead of Latin 'i' in an is_admin variable. Python treats these as distinct names because NFKC normalization does not map Cyrillic to Latin. The second technique inserts bidirectional override characters that reorder text for the compiler while the editor displays the intended order. The third hides zero-width characters inside string literals to break comparisons and searches. A compact Python auditor using the tokenize module and explicit character sets detects all three classes of characters. The article recommends adding such checks to CI pipelines and configuring linters including ruff and flake8 to reject suspicious commits.
redb 3.7.2 Released with Custom gRPC Protocol, Dependency Vulnerability Fixes and .NET 10 Migration
The redb ecosystem released versions 3.7.0, 3.7.1 and 3.7.2 in quick succession after 3.7.0 was withdrawn due to high-severity vulnerabilities in its .NET 9 build artifacts. NuGet audit detected issues only on full rebuilds, leading to updates for SSH.NET, Microsoft.Data.Sqlite, System.Security.Cryptography.Xml and Microsoft.Bcl.Memory across redb.Route, redb.Core, redb.Export and redb.Identity. The release introduces a native GrpcWire implementation that registers individual gRPC methods as routes on a shared Kestrel host, supports bidirectional streaming, real gRPC status codes and mTLS with pinned client certificates. redb.Route also gained a dedicated SOAP connector, Control Bus messaging for route lifecycle management and a corrected Claim Check pattern. File transports received critical fixes that prevent silent data loss when readLock and idempotency options are combined. All libraries now target net8.0;net9.0;net10.0 while host applications require .NET 10, aligning with Microsoft’s shortened support timeline for .NET 8 and 9.
Poisoned Rust Crates Execute Malware at Build Time: 245 Million Downloads Hit in Supply-Chain Attack
Three widely used Rust crates on crates.io were poisoned on August 20 with malicious versions that execute automatically during cargo build. The attack leveraged a typosquatted proc-macro1 dependency containing a build script that downloads payloads and establishes persistence. arrayref alone has accumulated 245 million downloads and is pulled automatically through caret ranges in many dependency trees. Attack infrastructure overlaps with prior campaigns attributed to Sapphire Sleet and MIDNIGHT NEPTUNE. Rust security teams yanked the malicious releases within 86-107 minutes, but the incident highlights missing publish-age controls and weak maintainer-account protections in the Cargo ecosystem.
PyPI Explores Prefix Reservation for Organizations Under PEP 752 to Prevent Name Squatting
PEP 752 proposes reserving package name prefixes for organizations on PyPI, allowing control over entire families of related package names rather than individual entries. The change addresses dependency confusion and name squatting risks where attackers register packages with familiar prefixes like google-cloud- or opentelemetry- to exploit user trust. Analysis of over 800,000 PyPI projects by CodeScoring shows that prefixes are rarely controlled by a single owner, with ecosystems like aws- managed by hundreds of accounts. The proposal introduces implicit namespaces and new metadata for clients and proxies while preserving the flat namespace model familiar to Python developers. PEP 755 will define the governance process for granting prefix rights, limiting applications to organizations and requiring clear justification. Existing packages receive backward compatibility exceptions, and the mechanism does not transfer across repositories.