macOS - Software Lifecycle - Patch Adobe Reader With Notifications

What the Adobe Acrobat Reader patcher does

This Automox Worklet™ patches Adobe Acrobat Reader on macOS endpoints to the latest version published in the Automox software cache. Before forcing the Reader process to close, the Worklet uses the Automox Notifier to present the signed-in console user with an Update or Cancel dialog so they can save open PDFs first.

The Worklet reads the installed Reader build from /Applications/Adobe Acrobat Reader.app/Contents/Info.plist (or the legacy Adobe Acrobat Reader DC.app bundle), compares CFBundleVersion against the latest build returned by the Automox getLatestVersion cache endpoint, and exits compliant when the two match. When the versions differ, the remediation script downloads the matching AcroRdrDC pkg through the Automox ottopm download tool, mounts it, runs the macOS installer, and verifies the resulting CFBundleVersion.

If the upgrade fails at any step, the Worklet restores the original application bundle from Adobe Acrobat Reader..bak so the endpoint is never left without a working Reader. After a successful install the Worklet attempts to relaunch Reader as the console user with su -l so end users do not have to reopen the app manually.

Why patch Adobe Acrobat Reader with a user prompt

Adobe Acrobat Reader is a recurring vulnerability target on macOS. Adobe ships security updates for Reader on a roughly quarterly cadence, with out-of-band releases for actively exploited bugs in font parsing, JavaScript execution, and the embedded PDF rendering engine. Endpoints that drift on Reader builds carry known CVEs that an attacker can land through a single malicious PDF attachment.

A silent patch policy that kills Reader without warning generates help-desk tickets from end users who lost unsaved annotations or in-progress form data. The Automox Notifier dialog in this Worklet bridges the gap: the security update still lands inside your patch window, but the end user gets a chance to save and accept the close. If the user declines, the Worklet exits non-zero and the endpoint is re-evaluated on the next policy run, so patch cadence is preserved without trampling active work.

How the Adobe Acrobat Reader patch flow works

1. Evaluation phase: The Worklet verifies that /Applications/Adobe Acrobat Reader.app exists, exits 0 if Reader is not installed, then queries the Automox cache endpoint at api.automox.com/api/cache for the latest adobe_acrobat_reader_dc_full build. It reads the installed CFBundleVersion with defaults read on the Info.plist (falling back to Adobe Acrobat Reader DC.app for legacy bundle names). If the installed version matches the latest, the Worklet exits 0; if it differs, the Worklet exits 1 and remediation is scheduled.

2. Remediation phase: The Worklet renames the legacy DC bundle to Adobe Acrobat Reader.app if needed, identifies the console user with scutil, and downloads the latest pkg through /usr/local/bin/wdk ottopm. If a Reader process is running, it invokes the Automox Notifier with an Update or Cancel dialog and a 180-second timeout. On Update, it pkills Adobe, waits up to 30 seconds for the process to exit, backs the existing app up to Adobe Acrobat Reader..bak, runs the installer, and relaunches Reader as the console user. On Cancel, install failure, or version mismatch after install, the Worklet restores the backup and exits 1.

Adobe Acrobat Reader patch requirements

• macOS workstation with Adobe Acrobat Reader already installed at /Applications/Adobe Acrobat Reader.app or /Applications/Adobe Acrobat Reader DC.app

• Automox agent installed with the Automox Notifier helper present at /Library/Application Support/Automox/Automox Notifier.app

• Network reachability to api.automox.com so the Worklet can fetch the latest Reader build manifest and download the AcroRdrDC pkg through ottopm

• Sufficient free space in /Applications for a temporary Adobe Acrobat Reader..bak backup and an Adobe Acrobat Reader.new staging directory during the install

• An active console user session is required for the Update prompt; if no console user is signed in, the Worklet only patches when Reader is not running

Expected Adobe Acrobat Reader state after patching

The endpoint reports Adobe Acrobat Reader at the latest CFBundleVersion returned by the Automox cache, the application bundle lives at /Applications/Adobe Acrobat Reader.app, and the Adobe Acrobat Reader..bak and Adobe Acrobat Reader.new staging directories are cleaned up. If Reader was running and the user accepted the prompt, the app is relaunched in the console user's session. Subsequent evaluation runs exit 0 until Adobe publishes a new build.

Verification: Run defaults read "/Applications/Adobe Acrobat Reader.app/Contents/Info.plist" CFBundleVersion and compare the output against the latest build at the Automox cache URL https://api.automox.com/api/cache?cmd=getLatestVersion&name=adobe_acrobat_reader_dc_full&os=Mac&arch=64. On a failed run, check the Automox Activity Log for the rollback path: messages beginning with "Worklet failed to take backup", "Removing new version", or "Restoring Backup" identify which workletCleanup branch executed. If the end user dismissed the Update prompt, the activity log records "User did not accept this update" and the next policy evaluation will reschedule the patch.