openSUSE Leap 15.5 — golang-github-prometheus-alertmanager — vulnerability — patch and remediation guide

📖 ~4 min read  •  Source: SUSE advisory SUSE-SU-2024:0191-1 (see also SUSE bugzilla)

Related CVEs: CVE-2023-40577

Upstream summary: Alertmanager handles alerts sent by client applications such as the Prometheus server. An attacker with the permission to perform POST requests on the /api/v1/alerts endpoint could be able to execute arbitrary JavaScript code on the users of Prometheus Alertmanager. This issue has been fixed in Alertmanager version 0.2.51.

Table of contents

1. Symptom & Impact
2. Environment & Reproduction
3. Root Cause Analysis
4. Quick Triage
5. Step-by-Step Diagnosis
6. Solution – Primary Fix
7. Solution – Alternative Approaches
8. Verification & Acceptance Criteria
9. Rollback Plan
10. Prevention & Hardening
11. Related Errors & Cross-Refs
12. References & Further Reading

Symptom & Impact

On openSUSE Leap 15.5 hosts running golang-github-prometheus-alertmanager, the vulnerable code is started by something else – a web or application server, or an on-demand supervisor such as inetd, xinetd or a systemd socket unit – rather than by a service of its own. Patching replaces the files on disk immediately, but a long-running parent that has already loaded them (PHP-FPM workers, an application server, a persistent worker pool) keeps serving the old code until it is recycled. Connection-per-process supervisors pick the fix up on the next connection, so the exposure window differs sharply between the two and is worth confirming rather than assuming. golang-github-prometheus-alertmanager is started by a hosting server or an on-demand supervisor rather than by a unit of its own, so restart whatever launches it – not golang-github-prometheus-alertmanager.

Environment & Reproduction

Reproduction targets openSUSE Leap 15.5. Confirm release and installed package:

cat /etc/os-release
rpm -q golang-github-prometheus-alertmanager
zypper info golang-github-prometheus-alertmanager | head -20
zypper lr -E                              # enabled repositories
SUSEConnect --status-text 2>/dev/null || echo 'SCC not connected (optional on openSUSE Leap)'

Exercise the workload that uses golang-github-prometheus-alertmanager while collecting:

sudo zypper ps  # NATIVE SUSE TOOL, no extra package: every running process still using deleted/replaced files, plus the owning service name
sudo zypper ps -s  # short table (PID, PPID, UID, login, command, service) without the per-file detail
sudo zypper ps -sss  # service names ONLY, one per line - safe to pipe straight into systemctl
sudo journalctl -xe --no-pager | tail -200
sudo tail -200 /var/log/zypp/history
sudo journalctl -k | grep -i apparmor | tail -100
# Bundle evidence for SUSE / community support:
sudo supportconfig -R /var/tmp -B golang-github-prometheus-alertmanager

Root Cause Analysis

Root cause is documented in SUSE advisory SUSE-SU-2024:0191-1. openSUSE security maintainers shipped fixes in the corresponding golang-github-prometheus-alertmanager update for openSUSE Leap 15.5; running an outdated build leaves the host exposed to the failure modes described in the advisory. Correlate zypper history with system logs:

sudo zypper history | grep golang-github-prometheus-alertmanager
sudo zypper history --since='-7 days' | tail -40
sudo journalctl -k | grep -i apparmor | tail -100
cat /proc/sys/kernel/tainted   # non-zero = tainted kernel / out-of-tree modules

Quick Triage

Run these on openSUSE Leap 15.5 to capture the current state of golang-github-prometheus-alertmanager:

rpm -q golang-github-prometheus-alertmanager                              # installed NVR
rpm -V golang-github-prometheus-alertmanager                              # verify shipped files
sudo zypper patch-check                    # open patches
sudo zypper lp 2>/dev/null | head
systemctl --failed --no-pager
sudo firewall-cmd --list-all
sudo aa-status                             # AppArmor profiles
rpm -ql golang-github-prometheus-alertmanager | grep -E '^/(usr/lib|etc)/systemd/(system|user)/[^/]+\.(service|socket|timer|path|target|mount)$'  # the units golang-github-prometheus-alertmanager REALLY ships - NO OUTPUT means it ships no service at all, so never run systemctl on it
rpm -ql golang-github-prometheus-alertmanager | grep -E '^/usr/sbin/rc[^/]+$'  # SUSE-only rcNAME compat symlink (it points at /usr/sbin/service, not at a unit): the NAME after 'rc' IS the service name - bind ships /usr/sbin/rcnamed, so the unit is named.service

Step-by-Step Diagnosis

1. List failed systemd units.

   systemctl --failed --no-pager

2. Tail the journal for golang-github-prometheus-alertmanager and the system bus.

   sudo journalctl -xe -f --no-pager

3. Inspect firewall posture (firewalld is the default on openSUSE).

   sudo firewall-cmd --list-all-zones --permanent
   sudo nft list ruleset 2>/dev/null | head -50

4. Surface AppArmor denials and switch the profile to complain mode if needed.

   sudo journalctl -k | grep -i 'apparmor="DENIED"' | tail -30
   sudo aa-status

5. Verify golang-github-prometheus-alertmanager integrity and reinstall if anything is altered.

   sudo rpm -V golang-github-prometheus-alertmanager
   sudo zypper verify
   sudo zypper install --force golang-github-prometheus-alertmanager

6. Inspect Snapper snapshots to know exactly which transaction introduced the regression.

   sudo snapper list | tail -20
   sudo snapper status <pre-id>..<post-id>

7. Correlate findings with /var/log/zypp/history, zypper history, and SUSE advisory SUSE-SU-2024:0191-1 to pin the change that introduced the regression.

Solution – Primary Fix

Apply the corrective zypper transaction referenced by SUSE advisory SUSE-SU-2024:0191-1, then reload affected systemd units:

sudo zypper ref                        # refresh repos
sudo zypper -n patch                   # apply ALL open patches (recommended)
# Or target a single package:
sudo zypper -n update golang-github-prometheus-alertmanager
sudo systemctl daemon-reload
# Unit name may differ from pkg name; check first:
sudo systemctl daemon-reload  # load unit files replaced by the update; this alone restarts nothing
sudo systemctl restart UNIT1.service UNIT2.service  # restart several in ONE transaction - systemd applies their own After=/Before= ordering, so low-level units (dbus, database, broker) go before their consumers
sudo systemctl restart UNIT.service  # NOTE: 'systemctl reload' is NOT enough after a library patch - the process must re-exec to map the new .so
sudo systemctl reload apparmor.service  # only if 'rpm -ql golang-github-prometheus-alertmanager | grep /etc/apparmor.d/' showed the package ships AppArmor profiles
rpm -q golang-github-prometheus-alertmanager                           # confirm new NVR

For kernel / glibc / systemd / openssl advisories a reboot is required. Snapper takes pre/post snapshots on Btrfs root automatically, giving a safety net:

sudo zypper ps -s                      # services using deleted libs
sudo snapper list | tail -5            # pre/post snapshots around the patch
sudo systemctl reboot                  # or: sudo shutdown -r now

Solution – Alternative Approaches

If the primary fix is not viable, choose from these:

• Roll back via Snapper (Btrfs snapshots are taken automatically before zypper transactions on openSUSE Leap 15.5). This is the primary safety net for openSUSE administrators:

  sudo snapper list
  sudo snapper status <pre-id>..<post-id>   # diff between two snapshot numbers
  sudo snapper undochange <pre-id>..<post-id>
  sudo snapper rollback <pre-id>            # boot the host into the chosen snapshot
  sudo systemctl reboot

• Lock the package so zypper cannot upgrade it:

  sudo zypper al golang-github-prometheus-alertmanager                   # add lock
  zypper ll | grep golang-github-prometheus-alertmanager                 # list locks
  sudo zypper rl golang-github-prometheus-alertmanager                   # remove lock

• Install an older NVR if a regression is suspected:

  zypper se -s golang-github-prometheus-alertmanager                     # show all available versions
  sudo zypper install --oldpackage golang-github-prometheus-alertmanager-<older-NVR>

• Disable the AppArmor profile briefly to confirm policy is the cause, then re-enable:

  # reproduce, capture denials in the journal:
  sudo journalctl -k | grep apparmor | tail

• openSUSE Leap follows the SUSE Linux Enterprise patch stream. Sync against the official update repository if a mirror has drifted:

  sudo zypper mr -e repo-update          # ensure update repo is enabled
  sudo zypper ref repo-update
  sudo zypper -n patch

Verification & Acceptance Criteria

All of these should pass after the fix:

rpm -q golang-github-prometheus-alertmanager                                            # expected fixed NVR
sudo zypper patch-check                                  # 0 critical patches outstanding
sudo firewall-cmd --list-services
sudo aa-status | head -5
sudo zypper ps -s                                        # any services still using deleted libs

The conditions described in the advisory must no longer be reported for golang-github-prometheus-alertmanager across two consecutive runs.

Rollback Plan

Capture state before any change. On openSUSE, Snapper is the canonical rollback path:

rpm -qa > /root/rpm-pre.txt
sudo zypper history list > /root/zypper-history-pre.txt
# Snapper takes pre/post snapshots automatically on Btrfs root.
sudo snapper create -d 'pre-patch-golang-github-prometheus-alertmanager'   # explicit named snapshot
sudo snapper list | head

To revert if the patch / roll is bad:

# Preferred on Btrfs root — boot the prior snapshot:
sudo snapper list
sudo snapper rollback <pre-id>
sudo systemctl reboot
# Or downgrade just the package:
sudo zypper install --oldpackage golang-github-prometheus-alertmanager-<older-NVR>
sudo systemctl daemon-reload
# Custom AppArmor profile cleanup:

Prevention & Hardening

Reduce the chance of this recurring on openSUSE Leap 15.5:

• Enable automatic patch installation:

  sudo zypper install -y zypper-automatic
  sudo systemctl enable --now zypper-automatic.timer
  # Or use YaST: yast2 online_update_configuration

• Subscribe to opensuse-security-announce and watch suse.com/support/update.

• Lock sensitive packages so they cannot be auto-upgraded:

  sudo zypper al golang-github-prometheus-alertmanager

• Ensure Snapper is enabled on the root subvolume and pre/post hooks run for every zypper transaction. This is the cornerstone of safe openSUSE patching:

  sudo snapper -c root get-config | head
  # Default zypper plugin: /usr/lib/zypp/plugins/commit/snapper.zypp-commit-plugin
  sudo snapper list | tail -10

• Monitor file integrity with AIDE:

  sudo zypper install -y aide
  sudo aide --init && sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
  sudo aide --check

• Keep AppArmor profiles in enforce; review /etc/apparmor.d/ after every package upgrade.

• Apply CIS / openSUSE hardening guidance and use salt or ansible to enforce baseline state across the fleet.

Related Errors & Cross-Refs

Issues that commonly surface alongside a golang-github-prometheus-alertmanager update: zypper lock contention, systemd unit ordering cycles, AppArmor denials, firewalld zone drift, and kernel taint flags. Useful triage:

sudo zypper ps -s
systemd-analyze critical-chain
sudo journalctl -k | grep apparmor | tail
sudo firewall-cmd --get-active-zones
cat /proc/sys/kernel/tainted
sudo snapper list | tail

View all opensuse-leap-15-5 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

Primary reference: SUSE advisory SUSE-SU-2024:0191-1 (see also SUSE bugzilla). Manual pages useful on openSUSE Leap 15.5:

man zypper
man zypper.conf
man systemctl
man journalctl
man firewall-cmd
man snapper
man apparmor
man aa-status

Other resources: openSUSE documentation, suse.com/security, openSUSE security portal, and per-package notes in /usr/share/doc/packages/golang-github-prometheus-alertmanager/ for components implicated in this advisory.

View all openSUSE Leap 15.5 tutorials on the Tutorials Hub →