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
Should Python Libraries Raise Minimum Dependency Versions to Block Vulnerable Releases?
Seth Larson of the Python Software Foundation argues that library maintainers should not automatically raise the minimum allowed version of a dependency after a vulnerability is disclosed. He states that dependency metadata exists to declare compatibility, while security decisions belong to the application owner who controls the final build. The recommendation has sparked debate in the Python community, with some maintainers supporting the separation of concerns and others viewing security constraints as part of library support obligations. CodeScoring’s analysis examines the practical impact on the ecosystem, noting that over 10,000 packages depend on urllib3 and tens of thousands more rely on numpy, requests, and pandas. The piece concludes that version bounds may incorporate security considerations only after evaluating real usage, affected versions, and downstream compatibility, but they cannot replace application-level vulnerability management with lockfiles and tools such as pip-audit.
FakeGit Campaign Floods GitHub with 7,600 Fake Repositories to Distribute SmartLoader Malware
The FakeGit operation has created or repurposed approximately 7,600 repositories on GitHub to trick users and automated agents into downloading SmartLoader, a loader that installs additional malware including the StealC infostealer. Attackers clone legitimate projects, replicate documentation and developer profiles, and host malicious ZIP files in GitHub Releases that have already accumulated over 14 million downloads across roughly 200 repositories. A notable tactic called AgentBaiting targets AI systems by disguising more than 800 repositories as AI Skills or MCP servers, leading tools from Anthropic, Google, and OpenAI to recommend malicious packages. The infection chain uses LuaJIT to execute obfuscated Lua scripts that deploy SmartLoader, which establishes persistence via scheduled tasks and resolves command-and-control infrastructure through a blockchain dead drop on Polygon. Over 600 listings linked to the campaign have also appeared on public directories such as LobeHub, Glama, and MCP Market, extending the reach beyond GitHub. Defenders are advised to maintain approved catalogs of AI components, apply application control policies, and monitor for LuaJIT execution and anomalous outbound traffic.
Securing CI/CD in Open Source Projects: Cilium’s Final Guide to Credentials, Verification, and Remaining Gaps
VK Cloud has published the third and final part of its translated Cilium series on protecting the software supply chain in open source projects. The article details how Cilium isolates CI and production credentials using separate GitHub environments, enforces keyless signing with Sigstore Cosign and SBOM attestations, and applies strict release controls that prevent compromised workflows from reaching production images. It also covers the team’s ongoing security operations, additional hardening measures such as immutable tags and mandatory DCO sign-offs, and a gap analysis against OpenSSF Scorecard and SLSA standards. The post examines GitHub’s 2026 Actions security roadmap and explains how planned platform features like dependency blocking, scoped secrets, and native egress firewalls align with Cilium’s existing controls. The piece concludes by emphasizing defense-in-depth and the importance of openly sharing supply-chain security practices across the open source community.
Understanding SCA: How Software Composition Analysis Helps Manage Software Supply Chain Risks
Software Composition Analysis (SCA) has emerged as a critical tool for organizations seeking to understand and control the risks hidden within modern applications built from third-party components, open-source libraries, container images, and transitive dependencies. SCA tools scan projects to identify components, versions, dependency chains, known vulnerabilities, and license issues, providing visibility that traditional security methods often miss. The approach supports SBOM generation and integrates with standards such as SPDX, CycloneDX, and VEX to improve transparency across the software supply chain. Organizations use SCA throughout the development lifecycle—from dependency selection and build-time gating to post-release monitoring—to reduce reaction time when new vulnerabilities appear and to manage technical debt, licensing conflicts, and abandoned packages. In regulated environments, including compliance with Russian standards like GOST R 56939-2024 and FSTEC requirements, SCA helps teams demonstrate control over software composition and prepare evidence for certification. While powerful, SCA is not a silver bullet: it relies on accurate data, cannot detect zero-days, and requires careful policy tuning to avoid alert fatigue or developer workarounds.