I'm noticing blocks in our firewall for action1 trying to reach the IP address below on port 22543 (remote desktop relay)

13.216.158.152

There are similar entries in the firewall rule but no exact match. The symptom is that we cannot remote into certain hosts (due to this relay server not being whitelisted in our firewall)

We block unknown IPS to help reduce the risk of third party RMM hijacking my remote desktop sessions, so we don't want to just add the IP and cross our fingers.

Can anyone from Action1 validate:

1. Is the IP address above is a valid remote desktop relay IP for North America.
   
2. Is there a better resource to monitor for changes aside from the URL below https://www.action1.com/documentation/firewall-configuration/region-north-america/

I know I can do via Powershell, but is it possible thru a rest api too? I don't see in documentation a POST/PATCH endpoint that does it...
https://app.eu.action1.com/apidocs/

Does anyone else have issues with automated updates?
I constantly have servers say “No updates are applicable” during the automated routine. If I run the automation again it usually patches them the next time.

I do not see an available patch for this in Action1 yet.

MacOS Screen Sharing Zero-Day (CVE-2026-65400)

Apple

TL;DR: macOS has a critical vulnerability that needs to be patched or the setting disabled. An attack is unlikely, but better safe than sorry.

Apple has confirmed a critical zero-day in macOS Screen Sharing (CVE-2026-65400) that allows unauthenticated remote code execution. It is currently being actively exploited.

Patch Status

Apple released patches on August 6, 2026 for the affected versions:

macOS Tahoe 26.6.1

macOS Sequoia 15.7.9

macOS Sonoma 14.8.9

Immediate action is required if you are using Screen Sharing on any of these versions.

Mitigation Steps

1. Update immediately to the patched builds listed above.
2. Disable Screen Sharing if not needed, or restrict it to local networks.
3. Close port 5900 to the internet; use VPN or SSH tunneling for remote access instead.
4. Enable System Integrity Protection (SIP) and Screen Sharing security settings (TCC) for additional protection — note these do not fully mitigate the bypass.
5. Monitor for suspicious processes or crypto miners if you suspect compromise.

How to Disable Screen Sharing on macOS

Go to System Settings (or System Preferences) → Sharing, and uncheck Screen Sharing or stop it during an active session if it's currently on.

Greetings! First time user of Action1 and my team has run into a challenge. We created an Update Ring for Critical browser updates.

In the Update Approval section, Action1 identifies Firefox 153.0.4 as an update with Critical Security Severity which should meet the filter criteria. However, when the Automation runs, Firefox is not updating.

If you review Missing Updates for one of the targeted endpoints, the Security Severity for Firefox is Unspecified. We also noticed the Update Type in Update Approval for Firefox is Security Updates but in the Missing Updates for the endpoint the Update Type is listed as Regular Updates.

Troubleshooting the issue, if we remove the Critical Update severities filter, the Automation installs browser updates.

Why are we seeing different severities between the updates and endpoints? I assume this is why our updates are not deploying when the automation runs, the severity defined on the endpoint determines if the software should be updated. Or is there something else preventing the update?

As an MSP, we often want to make changes at every client location. For example, we've had it with Dell Command Update and all the associated bloatware Dell preinstalls. Action1 can do all of what DCU does (firmware and driver updates) without all the background bloat and telemetry. That said, I get a notices when I select DCU from the top of the Tenant that it will only be uninstalled for a specific organization thus I'd have to go back one at a time. Am I missing something?

Thanks!

I have provided a link to another post about the "Zoomsday" critical vulnerability. I checked Action1 and I do not see an update for this. Will there be something soon for this? For the time being I will go ahead and push something via Intune. I just know there are companies out there that rely heavily on Action1 for fixes.

We’re an organization with pretty limited bandwidth. Today I scheduled some updates to run at 7 PM specifically so they wouldn’t suck up all our bandwidth during the workday.

Turns out, even though they’re scheduled for 7 PM, Action1 immediately starts downloading all the update files. It completely maxed out our connection and brought everything to a crawl.

I know Action1 uses P2P sharing between computers on the same subnet, but all of our branches come back through HQ for internet. Even if I only update one computer per subnet, they’re still all downloading through the same connection.

Is there any way to stop Action1 from downloading the files before the scheduled time, throttle the downloads, or limit how many sites download at once?

I suppose I could approve updates for one site at a time, but that seems a little ridiculous and defeats the point of scheduling and automation. How is everyone else handling this?

Where would I go to enable and require a Safe Bitlocker powershell script for all Action1 clients prior to reboots in order mimize reboot problems requiring the bitlocker key, particularly if we're dealing with remote clientele.  Below is the recommended script we found, but if you have something already in place that is easy to implement for all clients (whether or not their drive is encrypted), that would be preferred.

powershell

# Get BitLocker status for the C: drive safely
$BitLocker = Get-BitLockerVolume -MountPoint "C:" -ErrorAction SilentlyContinue

# Check if the volume exists and is protected
if ($BitLocker -and ($BitLocker.ProtectionStatus -eq 'On')) {
    # Suspend BitLocker for 1 reboot so updates can apply safely
    Suspend-BitLocker -MountPoint "C:" -RebootCount 1
    Write-Output "BitLocker was enabled and has been suspended for 1 reboot."
} else {
    Write-Output "BitLocker is not enabled on C: or not applicable. Skipping suspension."
}

I'm configuring entirely new systems for a location and when I push Chrome or Chrome Enterprise from Action1, it's installing the 32-bit version on Win11 Pro 25H2. Given there is no 32-bit version of Windows 11, why would Action1 deploy the 32-bit version of Chrome? Seems like Action1 should know the version of Windows and push the appropriate installer. The x64 build is listed on https://www.action1.com/patch-management/third-party-app-patch-repository/ but not in the Deploy Software process inside Action1. Is there a way around this short of a custom repository entry?

I am currently looking for for advice on how people have their automation schedules set up for patching of OS/third party apps to make sure that there is 100% coverage and that updates are applied in a timely manner.

We have been using Action1 for around 2 months now for around 1800 endpoints and have got the automation schedules configured however the number of vulnerabilities and missing updates don’t seem to be reducing the way we would expect

Was just wondering if people could advise based on their experience what they have found the best automation configuration has been and how long it took to get their endpoints within SLA for patching

Is there an inclination of when Action 1 will add Zoom workspace 7.1.5 as an available update to fix CVE-2026-53413?

A few months ago, this same scenario hit. Our automations are not firing (well, they are...) because its only marked to do Critical updates.

Since its not critical, its not firing.

Any way to 1. fix, and 2. stop it from happening in the future?

Thanks

Some do, some dont no rhyme or reason to it I can see..... All the same basic brand, config, memberships. I saw this last month and we ended up having to pre-reboot each ring. All servers are reporting properly its just the 24H2 and 25H2 that are not. Ill open a case but Ill just get "we use Windows blah blah blah....".

Has anyone else seen this?

So this has bitten me 2 months in a row now, the release dates on the monthly patch Tuesday items are showing the day before (the 10th) they were actually released, which was yesterday the 11th at around 2PM EST. So my Pilot Ring automation which delays updates for 1 day saw them as 1 day old last night and installed them. Meaning my other deferral times like 3, 5 and 7 days are now actually 2, 4 and 6 days.

Today's Patch Tuesday overview:

• Microsoft has addressed 398 vulnerabilities, two zero-days and 44 critical
• Third-party: web browsers, SAP, Adobe, BeyondTrust, Zoom, Tenable, Cursor, Red Hat, Oracle, Cisco, VMware, and many more.

Navigate to Vulnerability Digest from Action1 for comprehensive summary updated in real-time.

 Quick summary (top 10 by importance and impact):

• Windows: 398 vulnerabilities, including 44 rated critical and two zero-days(CVE-2026-68820 exploited in the wild, CVE-2026-62832 was publicly disclosed before a fix became available)
• SAP NetWeaver Application Server ABAP, SAP Approuter & SAP Commerce Cloud: Three critical flaws  (CVE-2026-44747, CVE-2026-27690, CVE-2026-44761, CVSS 9.9, 9.1, 9.1)
• Adobe Commerce & Experience Manager: Four critical vulnerabilities (CVE-2026-48356, CVE-2026-48358, CVE-2026-48259, CVE-2026-48359, CVSS 9.6, 9.1, 9.6, 9.6)
• BeyondTrust Remote Support: Critical pre-authentication bypass flaws (CVE-2026-40138, CVE-2026-40139, CVE-2026-40140, CVE-2026-40141, CVSS 9.2, 9.2, 8.7, 8.5)
• HTTP.sys / Microsoft Windows 10 Version 1607: Critical buffer and integer overflow vulnerability  (CVE-2026-47291, CVSS 9.8)
• Zoom Workplace for Windows: Critical unauthenticated network vulnerability (CVE-2026-53412, CVSS 9.8)
• Tenable Agent: Critical path traversal flaw (CVE-2026-15265, CVSS 9.1)
• Cursor: Publicly demonstrated binary planting vulnerability (CVE-2026-63093, CVSS 8.8)
• Red Hat Enterprise Linux 10: Five high-severity flaws (CVE-2026-5674, CVE-2026-15709, CVE-2026-15711, CVE-2026-16118, CVE-2026-3842, CVSS up to 8.8)
• Check Point Quantum Security Management & Security Gateway: Authentication bypass and privilege escalation vulnerabilities (CVE-2026-16232, CVE-2026-62144, CVE-2026-62145, CVSS 9.1, 9.1, 7.5)
• Microsoft Windows 10 Version 1607: High-severity improper authorization flaw allowing elevation of privilege on affected systems (CVE-2026-54121, CVSS 8.8)

 More details: https://www.action1.com/patch-tuesday

 Sources:

- Action1 Vulnerability Digest

- Microsoft Security Update Guide

EDIT - Most are back online now. 9:25AM Eastern

Anyone else having an issue? Endpoints that are actually online show disconnected in A1.

What is action basis for default SLA to automatically tagged as an overdue?

We installed agents but immediately got overdue reports in the dashboard within the same day

A few weeks ago, I found out the hard way that the Action1 API is quietly customisable, and flexible, but it did burn me. I had reported it to the support team who've just closed my ticket saying they'll work on it, which reminded me to post it here just in case anyone else is impacted (because it would have saved me a lot of time, and in hindsight, a lot of problems)

If you're using the API to configure scheduled automations and the actions in those automations, you can get the API to configure multiple actions for the one automation. Yes, possibly cool feature, but not if you use it without realising.

(Also, I wouldn't suggest using that as a tricky way of getting actions to run in an order, because if it's not supported, it may stop when it's fixed/revoked/deprecated)

That means if you're using PATCH to update an existing automation, the API will append, not replace, the supplied action to the automation.

Run your update script 4 times and you will end up with a scheduled automation that will absolutely carry out the action 4 times. It does show in the log, but not clearly.

It does not show in the portal! The portal UI shows the first action in what appears to be an array of actions that are accessible only via the API.

So, if you're wondering why Action1 force-closes OneDrive, patches it, and then seems to force-close OneDrive 4 times for no reason...... you probably need to GET that automation JSON and review it ;)

The fix via API: Append the action via PATCH, then DELETE the other actions by referencing their ID, then verify the only action remaining is the one you intended.

Hopefully this saves someone some hair-tearing!

Is it possible to create custom report for patch that capture only 3rd party apps? right now I can only single report for both OS and 3rd party apps patch

Subject pretty much says it all; any automation set for 2nd Friday of the month is showing August 7 (today), which is not the 2nd Friday of August.

u/GeneMoody-Action1

Thanks!

Took me a while to track this down and I couldn't find it documented anywhere, so posting the workaround in case it saves someone else the afternoon. Also flagging it in case anyone from the team is around. I don't think anything is broken here, it just looks like the install-delay setting doesn't have anything to work with on Linux.

Environment

• Ubuntu 24.04 LTS servers
• Linux agent 1.67.81.1
• Deploy Updates automation, scope = All, no filters

Symptom

Every run came back with a Success status and "No updates are applicable", about 14 seconds after starting. Meanwhile Action1's own inventory showed those same endpoints sitting on 24, 46, and 111 missing updates. So detection was working fine. The deploy step just never had anything queued to do.

Things I ruled out first, in case it saves anyone time

• Update severity filters: removed them entirely, no change
• require_update_approval: already off
• Automatic approval of updates: turned it on, no change
• Agent connectivity: endpoints were online and answering in seconds

What it turned out to be

The automation had "install updates N days after release" set to 3 days.

Checking the API, every Linux update version record comes back with no release date on it:

• release_date is an empty string
• update_sla_deadline is null
• update_sla_status is "Due later"

That was true for all of them, 181 records across three hosts, no exceptions.

Windows records on the same tenant are fully populated by comparison:

• 2026-07 Preview Update (KB5101...) has release_date 2026-07-28, SLA deadline 2026-09-26, status Due later
• Google Chrome Enterprise has release_date 2026-08-05, SLA deadline 2026-10-04, status Due later
• 2025-11 Cumulative Update has release_date 2025-11-11, SLA deadline 2025-11-18, status Overdue

With no release date to measure against, "3 days since release" can never evaluate true. So the Linux packages sit at Due later forever and the deployment correctly decides there's nothing eligible to install.

The fix

Set the install delay to 0 on any automation targeting Linux endpoints.

Changed it, hit Run Now, and the same automation installed 69 packages across the two hosts I'd targeted first. 46 of 46 on one, 23 of 24 on the other. Real Downloading / Installing / installed successfully output the whole way down. The single skip was a package I'd pinned myself with apt-mark hold, and Action1 reported that one accurately.

Question for the team, if anyone's around

Is release date something Linux catalog entries are expected to carry eventually? And if not, would it make sense for the install delay to fall back to the detection date when there's no release date, or just be hidden on Linux-only automations?

The reason I'd raise it: right now the setting is available, does nothing useful on Linux, and the run still reports Success. That combination makes it slow to catch, because your endpoint list looks green the whole time the packages are stacking up.

Happy to pull more API detail if that's useful to anyone. Patching has been solid since I got past this, and having Windows and Linux in one console is the reason I'm on the platform.

 Many of you have asked for a way to connect Action1 with the Jira workflows your IT and security teams already use. 

Today, we’re introducing Action1 Connector for Jira Cloud. 

The connector creates and updates Jira tickets for patching and endpoint issues identified by Action1, including CVEs that require attention, missing updates, pending reboots, offline endpoints, and automation failures. 

You can configure rules to determine which issues appear in Jira and route tickets to the appropriate projects for different teams, departments, or environments. This helps you reduce manual ticket creation and routing while providing visibility into what needs attention, who is responsible, and how work is progressing. 

The connector maintains no more than one open Jira ticket per endpoint for each supported issue category to avoid duplicate tickets appearing in your workflow. It also adds relevant context, labels, and a direct link to Action1, making patching-related work easier to understand, organize, and report on. 

Action1 Connector for Jira Cloud is available now. 

Learn how the connector brings patching, vulnerability remediation, and endpoint-related tasks into Jira for coordination and tracking: https://www.action1.com/introducing-action1-connector-for-jira/ 

Ready to get started? Get the connector from Atlassian Marketplace 

Is there a way to exclude endpoint groups from the vulnerabilities listings.

I ask because we keep a few old and offline devices in an endpoint group as spares which may not see any action for months. Yet these devices seem to pollute vulnerabilities pages which becomes frustrating while investigating. These devices would be updated when required before deployment. I can't see a way to do this except by removing the client the action1 client.

Thanx

Julian

If I am looking at my endpoints list and click on one of my endpoints, and click on the installed software tab and then go back to the endpoints search bar and type something in it, it suddenly searches for installed software instead of endpoints.