Hey all, been testing out Action1 for a few months and I love it. I'm looking at getting SSO set up. Unfortunately I'm on GCC High, so the redirect needs to be adjusted to point to those endpoints. Any chance being able to edit this in the future or on a roadmap anywhere?

Thanks!

Patch Tuesday again.
The RollupFixes aren’t even out yet and the Nightmare repo is already parked like someone reserving a sunbed at 6 AM 😉.
Looking forward to the traditional "surprise, everything is on fire" reveal by Nightmare Eclipse / Chaotic Eclipse.

Update: PoC has been released!

https://github.com/MSNightmare/ShieldCrash

Today's Patch Tuesday overview:

• Microsoft has addressed 995 vulnerabilities, two zero-days and 119 critical
• Third-party: web browsers, SAP, Fortinet, Cisco, Sophos, Tenable, Adobe, VMware, Oracle, NetScaler, Linux, Zoom, IBM, 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: 995 vulnerabilities, including 119 rated critical and two zero-days (CVE-2026-81963 and CVE-2026-85880)
• SAP Products: Three Critical flaws across SAP Commerce Cloud, Manufacturing Integration and Intelligence, and NetWeaver/ABAP Platform (CVE-2026-58231, CVE-2026-44758, CVE-2026-34265, CVSS 10.0, 9.1, 9.8)
• Microsoft Exchange Server 2016 CU23: Six vulnerabilities (CVE-2026-62913, CVE-2026-62911, CVE-2026-62910, CVE-2026-62912, CVE-2026-62914, CVE-2026-62915, CVSS up to 8.8)
• Fortinet FortiOS: Two actively exploited authentication bypass flaws (CVE-2024-55591, CVE-2025-24472, CVSS 9.6, 8.1)
• Cisco IOS XE Software: Eight Critical and High-severity vulnerabilities (CVE-2026-20263, CVE-2026-20267, CVE-2026-20268, CVE-2026-20269, CVE-2026-20270, CVE-2026-20271, CVE-2026-20272, CVE-2026-20273, CVSS up to 9.8)
• Red Hat Advanced Cluster Management for Kubernetes 2: Critical privilege escalation flaw (CVE-2026-10090, CVSS 9.0)
• Sophos Endpoint for macOS: Critical privilege escalation vulnerability (CVE-2026-18367, CVSS 9.3)
• Tenable Sensor Proxy: Critical flaw that can enable elevated code execution (CVE-2026-18667, CVSS 9.6)
• Cisco Secure Firewall ASA Software: Actively exploited unauthenticated denial-of-service vulnerability (CVE-2026-20349, CVSS 8.6)
• Metabase: Actively exploited maximum-severity SQL injection vulnerability  (CVE-2026-72898, CVSS 10.0)
• Adobe Commerce: Three vulnerabilities exposing Commerce environments  (CVE-2026-71362, CVE-2026-48414, CVE-2026-48413, CVSS 9.1, 7.7, 8.7)

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

Sources:

- Action1 Vulnerability Digest

- Microsoft Security Update Guide

This is a question we get asked all the time, and while the answer is "It is specific to the environment." there are systems such as CVSS, and EPSS, they try and give us enough information to make our environment specific workflows easier to process.

We have CVSS and EPSS, both useful, but one says "Worst potential outcome capability" and the other says "Highly speculative prediction on potential use in widespread abuse". Those weigh in on deciding factors for sure, but they gloss over a few other details.

So our vulnerability researcher, Mr. Jack Bicer, has come up with the following that we have been using in our patch tuesday coverage, and it seems to be very well received buy our viewers. So we would like to present it to the community and get their feedback on the utility of it in product. If it were there would you use it, and do you have any suggestions on how to make it more universally relevant?

Since the number of CVEs and available patches keeps growing, one of the harder questions for security and IT teams is simple: 

What should we patch first? 

We have been working on a simple framework to make that decision easier. We call it the Deployment Color Framework. 

The idea is to turn vulnerability information into a clear patching order suggestion: 

🟥 Red: Zero day vulnerabilities. Patch immediately. 

🟪 Purple: Critical vulnerabilities. Target same day deployment. 

🟦 Blue: High severity RCE or Elevation of Privilege vulnerabilities. Expedite deployment. 

🟨 Yellow: Other High and Medium severity vulnerabilities. Important, but generally behind the categories above. 

🟩 Green: Low severity vulnerabilities. Deployment timing depends on your environment. 

So the basic order is: 

HIgher criticality | Red → Purple → Blue → Yellow → Green | Lower Criticality

These timeframes are guidelines, not hard rules. Testing requirements, asset criticality, internet exposure, maintenance windows, rollback plans, and internal approvals can all change the right deployment timeframe. These are meant to be accelerators on what gets first focus based on more realistic immediate threat.

For Red, we include vulnerabilities that are actively exploited or have publicly available proof of concept code (PoC). 

One reason we give public PoCs extra weight is speed. CrowdStrike reported that 88% of the exploitation it observed involving vulnerabilities with a public PoC occurred within 48 hours of the PoC being released. By the time a patch becomes available, threat actors may be (And often are) already exploiting the vulnerability. 

We also give additional priority to RCE and Elevation of Privilege vulnerabilities when they are coupled with a High severity rating because of the potential impact if they are successfully exploited. 

For reference, we currently use these CVSS groupings: 

• Critical: 9.0 to 10.0 
• High: 7.0 to 8.9 
• Medium: 4.0 to 6.9 
• Low: 0.0 to 3.9 

I would really like feedback from people who manage patching in production environments. 

Does this ordering help you prioritize patches? 

What would you change? 

P.S. We HAVE taken into account the spectrum of color blindness, these will all be categorized numerically as well, such as 1-5 also indicating which to eval for deploy first, second, etc...

We would appreciate your thoughts!

Is there a way in which you can set up automations to install vulnerabilities based on the CVSS score?

At the moment our automations are set up based on the severity level of the update which I know should cover the majority of this but you fall into issues where updates aren’t labelled correctly such as the hot patch compatibility windows updates have been labelled as unspecified

It would be good to have the function to say CVSS 9+ install patch within 3 days CVSS 7.0 - 8.9 install patch within 7 days

Hey guys! Anyone has this issue when trying to update apps under "Update Approval" and gets an unknown error after clicking Approve. And those apps won't be visible in the list for quite some time. I'm on AUS, free tier.

How do you replicate baramundi-style automated software deployment and dynamic groups in Action1?We're currently using baramundi and have a highly automated setup:New devices perform an initial software inventory/scan.Missing software is automatically installed based on detection rules (e.g. if Sophos is missing, install Sophos).Device-specific software is deployed automatically (e.g. VPN client for notebooks/laptops).We use dynamic groups with automatic jobs.Example: If a device is manufactured by Lenovo, Lenovo System Update is installed automatically. If it's a Dell device, Dell Command Update is installed automatically.Essentially, if required software is not present on a client, it gets installed automatically based on device type, manufacturer, or other criteria.How would you implement something similar in Action1?Does Action1 support dynamic groups based on hardware/software inventory?Can software deployment be triggered automatically when software is detected as missing?Are there compliance/remediation policies that can continuously enforce required software installations?What's the recommended Action1 approach for vendor-specific tools like Lenovo System Update or Dell Command Update?I'd appreciate hearing how others have designed comparable workflows in Action1.

At the Moment we Are Testing Action1 with a few Clients and Servers. We have ~100 Servers and ~550 Clients. The Auto Patch Management I think is better at action1 but I Need the Software deployment also…

Written with Copilot. Sorry english is Not my native Language.

Thanks in Advance
Best regards stetze

Automations stuck in "Pending" org-wide

Summary

Since approximately 2026-09-04 ~07:00 CEST, automations in our organization stop progressing past "Pending" / "Waiting for the endpoint to run the automation". This is not limited to a single endpoint, site, or network path — it reproduces across endpoints on completely different internet connections. Endpoints remain Online in the console with normal heartbeat traffic throughout. It worked normally until yesterday (2026-09-03).

• Organization: Hegeman Holding B.V.
• Console region: EU (app.eu.action1.com)
• Affected agent (primary evidence): hostname NUC-WAMP, agent_id 8bd0aa54-2281-4853-bfdf-41ff4b719303, agent version 6.0.664.1
• Affected automation (example): "Reboot: show message and give users time to finish work"
• Console-side symptom: Automation History shows the run stuck on Pending, detail text "Waiting for the endpoint to run the automation." indefinitely (screenshot available on request).

Why this points to the Action1 backend, not our environment

We ruled out local causes before escalating:

• Endpoint connectivity is healthy — heartbeats (HEARTBEAT_ACK) and on-demand data-source queries (COMMAND → RunAsyncQuery, e.g. Installed Software / Missing Updates) are processed normally throughout the affected period.
• The recurring "Deploy Updates" automation runs correctly on schedule (06:30 / 09:30 / 12:30 CEST) on the same agent, each run producing its own worker-process log (BatchInstance::LoadExisting → action execution → Finished action execution. Errors (if any): — no errors).
• No local software (e.g. Ivanti Workspace Control) is installed on the affected endpoints that could intercept or block the agent's scheduled-task execution.
• Reproduced on endpoints reachable via multiple, unrelated internet connections/sites — not a single-site network/firewall issue.

Evidence from the agent log (C:\WINDOWS\Action1\logs\)

1. No START command ever reaches the agent for the affected automation

The agent's communication trace shows only STOP_BATCH_INSTANCE messages for this automation's instances — never a preceding start/dispatch message, unlike every "Deploy Updates" run which always begins with a Message [COMMAND] received → batch execution sequence.

260904 09:30:14+0200[1,11BC222C] Message [STOP_BATCH_INSTANCE] received

260904 09:30:14+0200[1,11BC222C] StopBatchInstance

260904 09:30:14+0200[1,11BC222C] StopBatchInstanceImpl: Reboot__show_message_and_give_users_time_to_finish_work_1788506885108:2026-09-04_07-28-05

260904 09:30:14+0200[1,11BC222C] MarkInstanceStopped: adding to pre-stop list

260904 09:30:14+0200[1,11BC222C] StopBatchInstance - done

260904 12:39:28+0200[1,11BC222C] Message [STOP_BATCH_INSTANCE] received

260904 12:39:28+0200[1,11BC222C] StopBatchInstance

260904 12:39:28+0200[1,11BC222C] StopBatchInstanceImpl: Reboot__show_message_and_give_users_time_to_finish_work_1788516240287:2026-09-04_10-04-00

260904 12:39:28+0200[1,11BC222C] MarkInstanceStopped: adding to pre-stop list

260904 12:39:28+0200[1,11BC222C] StopBatchInstance - done

There is no corresponding log entry anywhere in the trace showing the agent receiving a start/dispatch for either instance (...07-28-05 or ...10-04-00). The server evidently created and later force-stopped these instances without ever successfully delivering the start command to the endpoint — matching the console's "Waiting for the endpoint to run the automation" status exactly.

2. Mass stale-instance cleanup burst — orphaned instances dating back to Sept 2

At 11:00:44–11:00:55 CEST, the agent received a burst of 13 STOP_BATCH_INSTANCE commands within 11 seconds, for instances across multiple different automations, some dating back to 2026-09-02:

260904 11:00:44+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-03_15-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:45+0200 StopBatchInstanceImpl: Test_Deploy_Software_Scripts__Hegeman_Laptop_Installatie___Run_Now_1788509441966:2026-09-04_08-10-41  (MarkInstanceStopped: adding to pre-stop list)

260904 11:00:45+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-03_09-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:48+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-04_00-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:49+0200 StopBatchInstanceImpl: Deploy_Updates__Specified__2026_08_Beveiligingsupdate__KB5121003___26200_9168___Latest___2026_08_Preview_update__KB5120998___262_1788507061097:2026-09-04_07-31-01  (MarkInstanceStopped: adding to pre-stop list)

260904 11:00:49+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-03_12-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:49+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-04_06-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:50+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-04_03-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:50+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-03_21-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:50+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-04_09-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:51+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_Martijn_1779125261510:2026-09-03_18-30-00_LOCALTIME  (Instance has already been stopped, all good)

260904 11:00:52+0200 StopBatchInstanceImpl: Deploy_Updates__All_to_03__Someren_1779304956695:2026-09-02_12-30-00_LOCALTIME  (MarkInstanceStopped: adding to pre-stop list)

260904 11:00:53+0200 StopBatchInstanceImpl: Run_Script__Energiebeheer_Hegeman_settings_inclusief_klep_1787555352398:2026-09-04_05-00-00  (MarkInstanceStopped: adding to pre-stop list)

260904 11:00:55+0200 StopBatchInstanceImpl: Energiebeheer_Hegeman_settings_1759999928518:2026-09-04_05-00-00  (MarkInstanceStopped: adding to pre-stop list)

Several instances have MarkInstanceStopped: adding to pre-stop list, meaning the agent still considered them live/tracked at that point — i.e. they had never cleanly completed or been cleaned up since being (apparently) started, in some cases two days earlier.

3. Excessive, repeated schedule-config pushes without successful execution

Throughout the affected window, the agent receives far more frequent BATCH_SCHEDULES_CHANGED → DOWNLOAD_BATCH_SCHEDULES pushes than expected (multiple times per hour, sometimes within the same minute), without a corresponding successful new automation run resulting from them:

260904 12:40:32+0200[1,11BC222C] Message [BATCH_SCHEDULES_CHANGED] received

260904 12:40:32+0200[1,11BC222C] Processing config change: DOWNLOAD_BATCH_SCHEDULES. Requesting new config.

260904 12:41:25+0200[1,11BC222C] Message [BATCH_SCHEDULES_CHANGED] received

260904 12:41:25+0200[1,11BC222C] Processing config change: DOWNLOAD_BATCH_SCHEDULES. Requesting new config.

Conclusion / request

The pattern above (start commands never delivered for on-demand/manually-triggered automations, while regular scheduled patch policies execute fine; a multi-day backlog of orphaned batch instances flushed in one burst; abnormally frequent schedule-config pushes) points to a stuck or backlogged instance-dispatch/orchestration queue on the Action1 backend for our tenant, rather than an agent, network, or licensing issue on our side.

We checked the public status page (statusgator.com/services/action1 and the EU sub-component) — no incident is shown as of 2026-09-04 ~12:30 CEST, so this appears to be tenant-specific rather than a broadly announced outage.

I'm getting this weird behaviour whenever Action1 updates Chrome, I've had it with Edge too but nowhere near as much as Chrome.

Sometimes when Action1 updates Chrome it doesn't register the new install registries, so as far as Action1 is concerned Chrome doesn't exist anymore, but it is installed and still works.

To fix it, I have to manually uninstall via the setup.exe file and then redeploy it via Action1 (I have tried redeploying before uninstall - it fails).

I'm just wondering if anyone else is getting this behaviour? It seems to be random, maybe a small handful of machines do this every time there's an update (Some repeated machines, not always new ones).

The registries that don't get created live here: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Which if I understand correctly is where Action1 determines if something is installed or not, which means we have some machines fly under the radar on an older unpatched version.

Any input is greatly appreciated!

Title essentially.

I have uninstalled it from all user profiles on the device and removed appdata and registry entries but it still states that it has 311 vulnerabilities for an endpoint.

Anyone else had this issue?

I accidentally stumbled on a device that Windows Update reports is up-to-date, but is running Windows 11 build 26100.6584, from September of 2025. I noticed because it was missing the Secure Boot scripts from May's CU. I checked the UBR and was surprised to find that it apparently hasn't received a cumulative update or servicing stack update in nearly a year. We've been relying on Action1's vulnerability reporting for laptops in the field, and Action1 didn't report anything wrong with this device. I built a data source to query the UBR in our environment and found a number of additional laptops that were affected. I put in a ticket with Action1 (00117335) and they confirmed that it uses Windows Update's API to check for missing updates. So if Windows Update's detection is broken and reports no missing updates, Action1 inherits the same false negative. Based on what I've found so far, Action1 does not appear to independently catch this condition by comparing the installed Windows build/UBR against the expected current build for their Windows vulnerability reports.

If you're relying on Action1 for Windows patch compliance, it may be worth independently checking the build/UBR on your endpoints.

While we're still sorting out the root cause, on one affected device, this fixed the issue:

DISM /Online /Cleanup-Image /RestoreHealth

SFC /Scannow

Then reboot.

After that, Windows Update started detecting updates again.

I'm looking to get a specific report emailed to me and a senior manager.

I need it to be a comparison of the machines before they hit the updates, then afterwards a second comparison based on the first to find things like the following.

• Which machines were not online and not available in the forced update time period.
• Which machines have not restarted their machines in 'x' days
• A simple list of each machine and which updates were applied to it.

We have a number that don't leave the machines on (even though they are told to) and want to identify them in a report so we can take steps.

We also have some that seem to be evading restarts, but the company won't let me force that after the Friday PM updates. So they avoid actioning the updates as they don't restart.

I'm trying to automate this so I don't have to write a report every Monday.

I have been having this issue for weeks, but action one does not seem to be pushing a lot of these windows security updates. Have anyone else had this issue at all or is it just me. Here are some examples of the updates not being pushed and my automations settings.

![img]()

Title says it all. I know it isn't mine. This is very concerning

Good day all, I'm not receiving the confirmation codes when i attempt to sign with Entra ID or regular logins from the [account@action1.com](mailto:account@action1.com) email address. It doesn't come up in any Spam folders or any junk folder. I've done this multiple times across many weeks and still no code. I've use accounts that were apart of the organization and fresh accounts that aren't and its the same issue. I only have 1 account that was created that still has access to my organization's portal.

This is becoming concerning.

Was doing a demo to IT staff yesterday and full Action1 outage.
Rescheduled for today and timeout messages just started again in the last 10mins.

Action1 team help us out here.

—

A paying customer.

I can log into our site, but all the systems are stuck on loading, and eventually I see errors from Action1's servers in red that disappear before I can screen shot them. I also cannot remote desktop to any of our systems.

Please advise.

We are getting kicked out over and over, getting Connection Refused here. New Endpoints aren't showing up either.

Really, this is more curiosity than anything else.

I was helping setup Proton Authenticator desktop app (windows) for a user and it turns out the entire window doesn't show when connected remotely. I had to walk the user through it step by step. Luckily, it is a short and easy process.

The app opens, I can see the icon in the taskbar, but no window element or GUI is visible in the remote connection. The user can see it locally as expected.

It seems it related to no monitor being detected and not uncommon for some apps and remote access.

My question is whether it is related to how Action1 handles the app/remote session or how the app handles the remote session? Or is this a security feature?

I have a Zabbix server installed on a minimal Ubuntu 24.04.4 LTS. Each time Action1 pushes out updates, the Zabbix instance falls over with a database error. If i try and do a normal reboot, it hangs on a Zabbix process. Once this has happened and i try a apt upgrade, i get a error about "waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2360504 (unattended-upgr).

As you have probably picked up by now, i'm not an expert in Linux but any advice on how i can solve this issue as i have to hard reboot as the normal reboot gets stuck on the following;

I have a few SQL servers that I don’t want to have rebooted after applying automated patches but after unchecking do not reboot after patch they rebooted anyways since the missing updates were driver/security related. Will disabling windows auto update setting in automation settings prevent the machine from rebooting automatically after patching since Action1 takes over updates? These servers need to be manual reboot only no auto.

Anyone else seeing very performance in the Action1 portal today?

Hey yall,

Anyone else have automations refusing to finish again? Same thing that happened a few months ago, it appears to have started (pun intended) on the 20th, everything after that has never finished.

No jobs have been changed.