Just saw the security advisory pop up in my feeds. CVE-2024-3400, critical severity for PAN-OS 11.0, specifically for the GlobalProtect feature. Looks like it allows unauthenticated remote code execution? That's as bad as it gets.
Has anyone in the community rolled out the hotfix (PAN-OS 11.0.2-h3) yet? I'm particularly curious about:
* Any impact on active GlobalProtect VPN sessions during the hotfix application?
* Performance observations post-patch—any hiccups in throughput or logging?
* For those on 11.0.1 or earlier, are you jumping straight to 11.0.2-h3, or going to 11.0.2 first?
We're scheduling our maintenance window now, but real-world intel before we pull the trigger would be golden. Sharing your experience could really help others plan their rollouts.
Cheers, Henry
Cheers, Henry
We applied the hotfix to our primary data center firewalls last night. To your specific points:
* Active GlobalProtect sessions were maintained, but we observed a brief spike in latency (approx 200ms increase) for about 90 seconds during the process. No disconnections.
* Post-patch throughput is unchanged in our metrics. However, the Dataplane logs showed a 10-15% higher volume of 'flow' type messages for the first hour before normalizing. This didn't impact storage, but monitor your log ingestion if you're piping to a SIEM.
* We were on 11.0.1 and went straight to 11.0.2-h3. The upgrade path was clean. The release notes for the hotfix explicitly state it includes all fixes from 11.0.2, so the intermediate step isn't required.
One caveat: if you're using any custom GlobalProtect portal or gateway configurations, do a config export first. Ours reverted to a default theme on one cluster member, requiring a quick re-import.
Data is the only truth.
I'm also staring at this advisory and trying to build our rollout plan. Thanks for laying out those specific questions, it's exactly the kind of stuff our security team is asking.
Our TCO process for emergency patches always forces us to weigh the risk of the exploit against the risk of the fix. For this one, the 'unauthenticated RCE' part is pushing us toward the fastest possible window, but I'm hesitant about the direct jump to the hotfix. Even if the release notes say it's okay, we've historically had a policy of stepping through major.minor versions first in our lab. I'm curious if others are feeling that internal policy conflict right now.
Has your team decided on the size of your maintenance window yet? We're debating between a late night and a full weekend slot, mostly because of that unknown about logging volume that user1504 mentioned. If our SIEM costs spike because of it, procurement will want an explanation.
I totally get the policy conflict. We had the same debate internally, especially when the exploit is this severe. Our compromise was to run the hotfix on a non-production firewall clone first. It took maybe 30 minutes to validate basic VPN and policy functions, which gave us enough confidence to bypass the step-up rule for this emergency.
> because of that unknown about logging volume that user1504 mentioned
If your SIEM cost is a factor, you could temporarily adjust your log forwarding filters for the firewall during the maintenance window. We throttled the `flow` logs to `warning` level for a few hours, just to prevent a data surge while things stabilized. That might help with procurement's questions.
For the window, we went with a late night slot. The active sessions staying up meant we didn't need a full weekend outage. Just plan for that initial log spike.
Testing on a clone is the right move. The 30-minute validation matches what we saw.
Your log throttling idea is smart, but be aware it can mask other issues. I'd keep threat logs at their normal verbosity. The flow log spike is just noise.
You don't need a weekend window. The brief latency bump user1504 mentioned is the main operational impact.
Trust, but verify