r/Citrix

https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX696939

The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities: 

• NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-73.32
• NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-63.21
• NetScaler ADC FIPS BEFORE 14.1-73.32 FIPS
• NetScaler ADC FIPS and NDcPP BEFORE 13.1-37.277

CVE-ID	Description	Pre-conditions	CWE	CVSSv4
CVE-2026-19489	Memory overflow vulnerability leading to unpredictable behavior or Denial of Service	SIP ALG(Session Initiation Protocol Application Layer Gateway) should be enabled on a Large Scale NAT (LSN) group configuration.	CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer	CVSS v4.0 Base Score: 8.8 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/ VC:L/VI:L/VA:H/SC:N/SI:N/SA:L)
CVE-2026-19490	Authentication bypass using an alternate path	The appliance must be configured as a Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or an AAA virtual server, subject to the following version-specific requirements: 14.1-43.56 or later: Applicable only when configured with a SAML action. 14.1-43.55 or earlier: Applicable when configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy ) or AAA vserver 13.1-61.28 or later: Applicable only when configured with a SAML action. 13.1-61.27 or earlier: Applicable when configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy)  or AAA vserver 13.1 FIPS: Applicable when configured with Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA vserver.	CWE-288: Authentication Bypass Using an Alternate Path	CVSS v4.0 Base Score: 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/ VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)

Steps to determine if an appliance meets the CVE preconditions

For CVE-2026-19489:

Customers can determine if the appliance meets the precondition by inspecting their NetScaler configuration for the specified string:

• "​add lsn group.*sipalg.*"

 

For CVE-2026-19490: 

Customers can determine if the appliance meets the precondition by inspecting their NetScaler configuration for the specified string:

SAML action configuration

• "add authentication samlAction.*"

 Auth or VPN vserver

•  "add authentication vserver .*"

Or 

•  "add vpn vserver .*"

My new shop is looking at adding a print management solution. I have used PrinterLogic at my last 3 employers, and have been asked about PaperCut. Who is using it and is it a headache to setup within mostly non persistent desktops?

We currently have two SDX appliances on premises, no service running on Cloud. The cost of the previous annual maintenance / support had always been priced based on a SDX hardware appliance. This year, Citrix switches to the Cloud based license pricing model. We are invoiced for ‘250 (QTY) CITRIX UNIVERSAL HYBRID MULTI-CLOUD.’ Does anyone know what this means? Can the quantity be changed?

We're migrating from vmware to hyper-V and we have multiple citrix environments with mas agents and fips vpx's that need to be migrated.

Currently each environment has it's own HA pair. I was thinking about trying this route:

Set the primary to stay primary, Breaking the ha pair, turn off the secondary (with the understanding that during the rest of this process we will not have redundancy). Then deploy a vpx in hyper-V (possibly using the same NSIP, since hte other one is off), make sure it's on the same firmware version as the remaining vmware vpx. Then add this new hyper-V vpx to the vmware one to creat a new HA pair. do the fips sync with this new vpx and iron out anything else that pops up, test that its working, fail over/fail back etc. Once that appears to be good to go, set the intiial primary to secondary, and the new hyper-V vpx to stay primary, break the ha pair again, and spin up a 2nd hyper-V vpx, then repeat that process.

I get that this is a round about way of trying to do this rather than just standing up 2 new vpxs in parallel then cutting over to them, but I'm thinking if this process works, then I save myself the headche of reconfiguring everything, dealing with needing to get new certs, potentially new gateway urls, punching network holes, etc). I've done the paralell setup in the past and it's fine, but I'm going to have to do 4 at once for this migration.

Would this work or am I not taking something in to account here?

Hi all,

We’re currently running our full Citrix backend on Windows Server 2019:

• 2x DDC
• 2x StoreFront
• 2x FAS

Environment is currently on CVAD 2402 CU3 LTSR.

Since 2402 CU3 doesn’t support Windows Server 2025, the plan is to first upgrade the Citrix environment to CVAD 2503 CU1 LTSR. That part is pretty straightforward.

The bigger question is the OS migration.

As far as I know, in-place OS upgrades for Citrix infrastructure servers are still not supported, so I’m wondering what the best practice is nowadays.

Is the recommended way still to build new Server 2025 machines alongside the existing servers, add them to the environment, move the roles/configuration over, and then remove the old 2019 servers?

We have close to 1,000 VDIs and quite a lot of Machine Catalogs and Delivery Groups, so I’d really like to keep downtime and risk to a minimum.

For the DDCs in particular, would you simply add two new Server 2025 DDCs to the existing Site, update VDAs/policies if needed, and then decommission the old controllers? This give me a headache bcause i have to open extra firwall rules regarding Netscalers in the DMZ.

And for StoreFront and FAS, same idea: build new, join/migrate, test, then remove the old servers?

Has anyone done a similar 2019 → 2025 migration in a larger Citrix environment?

Would be interested to hear what migration order you used and if there were any gotchas.

Unable to share my screen in MS Teams running inside Citrix. It only shows the Window sharing option (no full-screen option), and when I select a window, sharing immediately stops.

Screen sharing works fine on Teams web, so this seems specific to the Citrix app.

Support teams from my company is helpless, they've tried multiple resolutions, nothing worked.

Anyone faced this or know a fix? Is this some kind of configuration issue ?

I understand Netscaler VPX does not support live migration on Hyper-V: VPX FAQ . How is everyone dealing with this in a Hyper-V cluster, particularly for cluster updates/reboots/maintenance?

Using Possible Owner, force-tying the VPX to a single host and just shutting the VPX down with the host and letting automatic VPX HA failover do its thing?

Look the other way and use live migration anyway (what exactly isn't supported about it? I don't care about missing a couple packets at 4am)?

Automating/scripting VPX failovers to coincide with Hyper-V maintenance?

Thanks for any thoughts.