Enodia: Open-Source Go Tool Automates Service Inventory, EOL Tracking and CVE Correlation
A DevOps engineer running both a home lab and a large production environment grew frustrated with the inability to answer three simple questions: which exact versions of PostgreSQL, nginx and other services are deployed, which of them have reached or will soon reach end-of-life, and which carry known CVEs.
Initial attempts using Ansible playbooks to collect operating-system versions and export them into Google Sheets quickly proved unsustainable. The spreadsheets lacked diffing capabilities, contained no knowledge of support calendars, and could not reach services that do not expose SSH such as Jira, PostgreSQL, Redis or BMC interfaces.
After evaluating existing tools, none of which combined live service discovery, end-of-life calendars and CVE data, the engineer created enodia. The resulting single-binary CLI under the AGPL-3.0 licence reads a declarative YAML configuration describing every target and then interrogates each service with a purpose-built probe written in Go.
One hundred and twenty-three product-specific probes currently exist, covering Atlassian products, GitLab, Jenkins, TeamCity, SonarQube, Keycloak, Vault, Grafana, databases, message brokers, VMware ESXi and vCenter, Proxmox, NAS appliances, BMC cards, pfSense, RouterOS and 31 operating systems via SSH. A generic probe supports any remaining service via HTTP(S) plus regex or JSONPath extraction.
Enodia deliberately splits collection from evaluation. The command enodia collect produces an inventory.jsonl file containing only observed facts; enodia check later correlates those facts against support calendars and CVE databases. This separation allows inventory gathering inside closed networks and subsequent analysis where internet access or local CVE mirrors are available.
Instead of a single pass/fail verdict, the tool reports three independent axes: PATCH status (current or behind), LIFECYCLE status (active, security-only or EOL) and BRANCH status (latest, newer or newer LTS). These axes feed an overall severity of info, warn or fail that determines the process exit code, making the tool suitable for CI pipelines.
During development several non-obvious pitfalls were encountered and fixed. Early MySQL/MariaDB probes triggered the server’s max_connect_errors counter because they closed the connection before authentication; the current probe now performs a minimal login attempt so that the connection is counted as established. MariaDB’s version-string prefix “5.5.5-” caused older versions of enodia to misclassify servers as long-EOL MySQL 5.5.5. Debian point-release information is read from /etc/debian_version rather than the frozen VERSION_ID field. VMware “Update N” nomenclature is parsed into semantic versions so that 8.0 Update 3 is not reported newer than the calendar entry 8.0 U3k.
Support calendars are sourced primarily from endoflife.date, to which the author contributed full histories for Confluence, Bitbucket and Bamboo plus new entries for Jira Service Management and pgAdmin. CVE data is pulled from both NVD and Russia’s FSTEC BDU; package-level vulnerabilities for ten distributions are obtained via their native OVAL or Security Tracker feeds. All CVE databases can be updated once and then used offline inside air-gapped environments.
Related articles
Telegram Voice Call Flaw Allows Remote Code Execution on Android Devices
Security researchers disclosed a vulnerability in Telegram for Android that enables remote code execution on a victim's device simply by answering a voice call. The attacker requires only a standard account, and the flaw was present in versions 8.6.2 through 12.10.3 released between March 2022 and September 2026. Telegram addressed the issue in version 12.10.4, released at the end of September 2026. The root cause lies in improper handling of the MediaState message exchanged during calls, specifically when processing rotation values and missing video state fields, leading to out-of-bounds memory reads. The same underlying fix was deployed earlier to shared call libraries, iOS, and desktop clients, but reached Android later. Researchers confirmed the impact only on private calls running on ARM64 Android devices, with no evidence of exploitation in the wild or public CVE assignment as of October 29, 2026.
360 Security Cloud Opens PHP2Shell Vulnerability Self-Check Platform to Government and Enterprise Users
360 Security Cloud has launched a dedicated self-assessment platform that allows organizations to scan their PHP-based websites and systems for the PHP2Shell vulnerability. The service is now available to government agencies, large enterprises, and small-to-medium businesses. Users can apply by scanning a provided QR code to determine how many of their assets run PHP, identify affected versions, and check whether any systems have already been compromised. The platform addresses key questions about exposure: the number of PHP-powered sites and systems, the presence of vulnerable versions, and signs of prior intrusion. The announcement emphasizes that the tool helps organizations proactively assess risk without requiring external assistance. The original Chinese report was published on October 30, 2026, and the service is positioned as a practical response to ongoing PHP-related security concerns.
Liferay Community Edition Misconfiguration Exposes Plaintext Passwords in Government Systems via CWE-319
A detailed analysis reveals how the use of Liferay Community Edition in a closed government information system led to the transmission of user passwords in plaintext through transactional emails. The issue stemmed from default notification templates that included the [$PASSWORD$] macro, combined with unadjusted system variables pointing to localhost instead of the production domain. Despite proper OAuth 2.0 delegation and CSRF protections, the misconfigured password change workflow sent permanent credentials in clear text to user inboxes. The root cause was traced to custom portlets that incorrectly reused the New Password Notification trigger intended only for administrator-initiated resets. Remediation involves removing the password macro from email templates and updating portal-ext.properties to enforce production host settings. The case highlights how open-source enterprise platforms require thorough hardening beyond initial code audits when deployed in high-security environments.
GitLab Critical Vulnerabilities Traced to Ruby Onigmo Regex Engine, Including Exploited CVE-2026-97229
GitLab has disclosed that four critical vulnerabilities, including the already-exploited CVE-2026-97229, originate from flaws in the Ruby programming language's Onigmo regular expression engine rather than in GitLab code itself. The most severe issue, CVE-2026-97229, is an integer overflow in regex processing within CI/CD configuration files and carries a maximum CVSSv3.1 base score of 10.0. GitLab released patches on October 8, 2026, covering versions 19.4.2, 19.3.5, and 19.2.8. Ruby's development team followed with its own advisory on October 23, 2026, addressing the same underlying defects. The remaining three vulnerabilities involve double-free memory errors and additional integer overflows during regex parsing and compilation. Because the root cause lies in a shared dependency, any application or environment relying on the affected Ruby Onigmo engine may also be exposed.