Autoclean.sh Security Audit: December 2025 Findings

Hey there! We've just wrapped up a thorough security audit of the autoclean.sh script, specifically looking at the version released in December 2025. Our goal was to ensure this essential maintenance tool is as robust and secure as possible, safeguarding your Debian systems. We dive deep into the code, employing a mix of automated tools and good old-fashioned manual review to catch any potential vulnerabilities. So, let's break down what we found and what it means for you!

Executive Summary: A Secure Script with Room for Polish

When it comes to the security of autoclean.sh, we're happy to report that the script is secure for production use. Our analysis, which covered a substantial 3,812 lines of autoclean.sh code and an additional 904 lines for its notifiers, revealed no critical or high-severity vulnerabilities. This is a testament to the developers' commitment to secure coding practices. However, like any piece of software, there's always room for minor improvements. We identified one medium vulnerability and three low vulnerabilities, along with two informational points. These findings, while not posing an immediate threat, offer opportunities to further harden the script and enhance its security posture. The overall verdict? APPROVED FOR PRODUCTION USE – you can sleep soundly knowing autoclean.sh is handling your system maintenance with care.

Our Thorough Security Audit Methodology

To provide a comprehensive security audit report, we employed a multi-faceted approach. Our methodology is designed to catch vulnerabilities that might slip through a single tool or technique. First, we utilized Semgrep, a powerful static analysis tool, armed with custom rules specifically tailored for bash security patterns. This allowed us to automatically scan the codebase for known insecure coding practices and anti-patterns. Complementing Semgrep, we employed Grep for pattern matching, actively searching for notoriously dangerous commands and constructs such as eval, source, and common indicators of command injection. The automated scans are crucial, but they aren't the whole story. Therefore, a significant portion of our audit involved manual code review, where we meticulously examined critical functions, analyzed data flow, and traced the execution paths of sensitive operations. Finally, we applied Sequential Thinking Analysis, a method that involves deeply analyzing complex security implications by walking through the script's logic step-by-step, especially in intricate or less obvious scenarios. This rigorous process ensures that we not only identify surface-level issues but also understand the potential downstream effects of any discovered weaknesses.

MEDIUM Vulnerability: Plaintext Credentials Storage in autoclean.conf

One of the most significant findings in our security audit of autoclean.sh is a medium-severity vulnerability related to plaintext credentials storage. This falls under CWE-256, which specifically addresses the plaintext storage of passwords or other sensitive credentials. The issue is located within the autoclean.conf file, a central place where users configure the script's behavior and integrations. The Common Vulnerability Scoring System (CVSS) 3.1 score for this is 4.0, categorizing it as Medium. The problem arises because sensitive information, such as API tokens for Telegram, SMTP passwords for email notifications, NTFY tokens, and authentication headers for webhooks, are stored directly in the configuration file in plain text. This means that anyone with read access to this file could potentially gain access to these sensitive credentials. While the script does implement some mitigations – the configuration file itself requires root access to be read, and the credentials are intentionally masked when displayed in the UI (on lines 1533, 1543, and 1572 of the script) – storing them in plaintext still presents a risk. Our recommendations focus on enhancing the protection of this file. Firstly, we strongly advise applying chmod 600 autoclean.conf immediately after the file is saved. This command restricts read and write permissions to the owner only, significantly reducing the exposure. Secondly, it's crucial to document clearly for users that they must protect this file and ensure its permissions are appropriately set. Lastly, for even greater security, we suggest considering optional integrations with system keyring services or using environment variables, which can offer more secure ways to manage secrets than storing them directly in configuration files. By implementing these steps, we can significantly mitigate the risks associated with this finding.

LOW Vulnerability: Use of eval in safe_run() Function

During our security audit of autoclean.sh, we identified a low-severity vulnerability concerning the use of the eval command within the safe_run() function, located at line 2015 of the script. This falls under CWE-78, the category for OS Command Injection. The safe_run() function is designed to execute commands, and its implementation uses eval to interpret and run the command string passed to it. While eval is notoriously risky because it can execute arbitrary commands if not handled with extreme care, our analysis revealed that all calls to safe_run() in this script use hardcoded commands. These include apt update && apt install -y $packages_to_install, apt update, apt full-upgrade -y, flatpak update -y, and snap refresh. Crucially, the $packages_to_install variable, which is the only part that could potentially introduce variability, is constructed from a predefined whitelist of packages defined on lines 2527-2536. This means that no user-supplied input can directly influence the command executed by eval. Therefore, while the use of eval is generally discouraged, in this specific context, there is no exploitable path for command injection. The risk assessment concludes that the current implementation, despite using eval, does not present a security threat. Our recommendation is to document this design decision explicitly, explaining why eval was used and why it's considered safe in this particular scenario. No code change is strictly required for security purposes, but clear documentation ensures future maintainers understand the rationale.

LOW Vulnerability: TOCTOU Race Condition in Lock File Handling

Our security audit of autoclean.sh also flagged a low-severity vulnerability related to a potential Time-of-check Time-of-use (TOCTOU) race condition in how the script handles its lock file. This falls under CWE-367. The issue occurs in the code block between lines 2143 and 2151. Specifically, the script first checks if a lock file exists. If it does, it reads the process ID (PID) from it. Subsequently, it proceeds to write its own PID to the lock file. The theoretical race condition exists between the moment the script checks for the lock file's existence and the moment it writes its own PID into it. If another process were to create or modify the lock file between these two operations, it could lead to unexpected behavior. However, the risk assessment for this vulnerability reveals that it has a minimal impact. Exploiting this would require two root users executing the script simultaneously, and the consequence would be limited to the script potentially running twice concurrently, rather than a security breach. Furthermore, the lock file is located in /var/run/, a standard location for runtime files, and it is expected to have proper permissions. Given the low likelihood and minimal impact, our recommendation is to accept this risk. The complexity of exploiting it and the limited consequences mean that a code change is not deemed necessary at this time.

LOW Vulnerability: HTTP Protocol Allowed for Webhooks

An interesting point raised during our security audit of autoclean.sh is a low-severity vulnerability classified under CWE-319: Cleartext Transmission of Sensitive Information. This finding is less about a flaw in the script's code and more about a user configuration choice that could lead to insecure data transmission. The script allows users to configure webhook URLs using the NOTIFIER_WEBHOOK_URL variable. The vulnerability arises because users can specify a URL starting with http:// instead of the more secure https://. When an HTTP URL is used, any data sent to the webhook, such as system maintenance reports, is transmitted unencrypted over the network. This means that the data could potentially be intercepted and read by an attacker. Our risk assessment highlights that this is a user configuration choice rather than a direct code vulnerability. However, the potential for sensitive data interception is a real concern. Therefore, our primary recommendation is to enhance the user interface. Specifically, we suggest adding a clear warning that is displayed whenever a user configures a webhook URL using HTTP. This warning should inform the user about the security implications of using an unencrypted connection. By alerting users to the risks at the point of configuration, we empower them to make more secure choices.

INFORMATIONAL: Secure Temporary File Handling

During our comprehensive security audit of autoclean.sh, we specifically looked for any potential issues related to the handling of temporary files, a common vector for security vulnerabilities. We are pleased to report that under the Informational category, no issues were found in this area. The script demonstrates a strong understanding of secure file operations. We observed no instances where the script directly uses the /tmp directory or the mktemp command for creating temporary files. Instead, all file operations are directed to secure, predictable, and appropriately permissioned locations. Log files are stored in /var/log/debian-maintenance/, backup files are placed in /var/backups/debian-maintenance/, the lock file resides in /var/run/debian-maintenance.lock, and configuration files are kept within the script's own directory. This deliberate choice to avoid common pitfalls associated with temporary files significantly reduces the attack surface and reinforces the overall security of the autoclean.sh script.

INFORMATIONAL: Robust Supply Chain Security

In our ongoing security audit of autoclean.sh, we paid close attention to the script's supply chain security, and we're happy to report this aspect is properly controlled. This means the script is designed to prevent the installation of malicious or unintended packages. The mechanism for installing necessary tools is tightly regulated. As shown in the code snippet, the script explicitly defines a whitelist of tools that can be installed. For instance, timeshift, needrestart, fwupdmgr (which installs flatpak), flatpak, snapd, and smartmontools are the only packages that can be added to the $packages_to_install variable. This selective approach ensures that no arbitrary package names can be injected into the installation commands. By limiting package installations to this predefined, trusted list, autoclean.sh effectively safeguards against supply chain attacks where an attacker might try to trick the script into installing a harmful package. This control is a critical component of maintaining a secure system.

Security Controls Implemented: A Deep Dive

The autoclean.sh script incorporates several robust security controls designed to protect against various threats. Under Input Validation, the script employs validate_source_file() (lines 438-462) to block potentially dangerous characters and constructs like $(), backticks, pipes (|), and logical operators (&&, ||) within configuration, language, and theme files. This prevents simple forms of code injection. Similarly, validate_notifier_file() (lines 464-499) offers further protection by explicitly blocking dangerous commands such as eval, attempts to source remote URLs, curl | bash patterns, destructive commands like rm -rf /, disk manipulation commands like dd and mkfs, and overly permissive file modifications like chmod 777. These measures create strong barriers against malicious input. In terms of Access Control, the script correctly requires root privileges for execution (line 2119), ensuring that only authorized users can perform system-level maintenance. Log files are protected with chmod 600 (line 1971), limiting read access to the owner, and a lock file is maintained in /var/run/ (line 140) to prevent concurrent execution issues. For Secure Coding Practices, the script demonstrates diligence. Variable quoting is used consistently ("$variable"), which is crucial for preventing word splitting and globbing attacks. Error handling is robust, going beyond a simple set -e by including explicit checks for command success. A trap cleanup EXIT INT TERM is implemented to ensure that necessary cleanup operations are performed, even if the script is interrupted. Finally, the lock file mechanism includes PID verification, ensuring that the script doesn't overwrite a lock file from a different, legitimate process.

Comparison with Previous Audit: Significant Improvements

When comparing the current security audit findings for autoclean.sh with the previous report (documented in SECURITY_REPORT_ISSUE.md), it's evident that significant progress has been made in hardening the script. In the previous audit, there were six instances of eval usage. This has now been reduced to just one instance, with others being refactored to use the more secure declare -n (nameref) feature. This is a major improvement in mitigating potential command injection risks. Furthermore, the validation of source commands, which was a point of concern previously, has been confirmed as properly implemented and working effectively in the current version. The blocking of dangerous patterns, which were listed in the prior report, has also been verified and confirmed to be correctly implemented in the codebase. Overall, the codebase has been substantially hardened, demonstrating a strong commitment to addressing identified security weaknesses and improving the script's resilience against attacks.

Recommendations Summary: Actionable Security Enhancements

Based on our comprehensive security audit of autoclean.sh, we've outlined a set of actionable recommendations to further enhance the script's security. These are prioritized by impact and estimated effort. Our top recommendation (Priority 1, Low Effort) is to apply chmod 600 to autoclean.conf automatically after it's saved. This directly addresses the medium severity finding regarding plaintext credentials storage by ensuring the configuration file has the most restrictive permissions by default. Following closely, Priority 2 (Low Effort) is to add a warning to the UI when an HTTP webhook URL is configured. This addresses the low severity finding about cleartext transmission, educating users about the risks of using unencrypted connections. For documentation and clarity, Priority 3 (Low Effort) is to document security considerations in the README file. This ensures that users and future maintainers are aware of the security best practices associated with the script. Finally, for a more advanced security posture, Priority 4 (Medium Effort) suggests considering optional keyring integration for storing credentials. This would provide a more secure alternative to storing secrets directly in the configuration file, although it requires more development effort.

Conclusion: A Highly Secure Tool for System Maintenance

In conclusion, the autoclean.sh script demonstrates mature security practices that are highly commendable for a bash-based system administration tool. Our thorough security audit identified no critical or high vulnerabilities, leading to a final verdict of APPROVED FOR PRODUCTION USE. The script excels in several key areas: strong input validation effectively prevents a wide range of code injection attacks, the principle of least privilege is respected where feasible, and a defense-in-depth strategy is employed with multiple layers of validation. The single medium finding, related to plaintext credentials storage in autoclean.conf, is a common trade-off in configuration files and is significantly mitigated by the requirement for root access to read the file. The low-severity findings are either theoretical or related to user configuration choices that can be addressed with better warnings. We are confident in the security posture of this script and its suitability for maintaining your Debian systems.

For further reading on securing your Linux systems and best practices for script development, you can refer to these trusted resources:

• The Linux Foundation: For general Linux security best practices and training, visit The Linux Foundation.
• OWASP (Open Web Application Security Project): A great resource for understanding common web vulnerabilities and secure coding principles, including information on Command Injection.
• Debian Security Documentation: For specific security information related to the Debian operating system, consult Debian's official security pages.

Report generated by Claude Code security analysis pipeline

Appendix: Semgrep Scan Results

Here are the detailed results from the Semgrep scan, which formed a crucial part of our security audit of autoclean.sh:

Semgrep v1.146.0
Files scanned: autoclean.sh, webhook.notifier, telegram.notifier, email.notifier, ntfy.notifier
Critical findings: 0
High findings: 0
Medium findings: 0 (false positive filtered)
Low findings: 0

Note: It's important to mention that Semgrep encountered partial parsing issues with the complex heredoc syntax found within the bash scripts. To compensate for these limitations in the automated parser, our manual code review was particularly diligent in these sections, ensuring that no vulnerabilities were missed due to the tooling's constraints. This combination of automated scanning and thorough manual inspection is key to a reliable security audit.