Not necessarily a concrete security risk, as soon as you (the IT admin) are prepared to the new risks.
Strenghtened procedures
If you have a single certificate for many domains, it's a single point of failure and weakest chain ring. You need to enforce expensive IT procedures to keep its private key "eyes only" or better "HTTPS server only". Compromise of the single key will impact all services at once. Your entire business depends on a sigle 4096-bit long number
Possible availability issues
When a single key is shared across several services in a CDN, its compromise will bring the entire CDN down for the period of renewal of the key. Adding a new domain for service involves re-issuing the certificate with its associated downtime.
Load balancing effective
There is one advantage of using such shared certificates. In a CDN, you can effectively set up HTTPS proxies. This is a widely used practice and has great performance advantages.
Basically your DMZ hosts a set of load-balanced reverse proxy servers that will receive HTTPS traffic, decrypt it, and forward HTTP (notice, no S) traffic to the real servers inside the CDN network. This requires a strong setup of the internal network to ensure packet security but there are professionals working at that, and remember that the unencrypted traffic flows only within a trust zone.
So why load balancing? Because if your CDN hosts 1000 sites and a few of them get a traffic increase, you don't need to provision machines for them. You can let the proxies work as round-robin.
No SNI
There is a technical reason behind multi-aliased certificates and it is that the CDN doesn't want to require SNI (Server Name Identification) from clients. Especially in the financial/enterprise world, some people's browsers may be too old to support SNI.
Provisioning a new certificate for each new service, with a different private key, is a good security practice.