A web server (let's say Apache 2.4) implements SNI. It is configured with a 4096 bit SHA384-signed Wildcard Certificate (*.land.org) with a Subject Alternative Name (land.org). The Certificate Authority has a trusted path to a SHA-2 signed root certificate as well as a second trusted path to a SHA-1 signed root certificate. Let's also say that this web server implements what is currently considered to be secure renegotiation.
The web server is configured for a default Virtual Host (wonder.land.org) with only SSLv3 enabled, with an SSL certificate containing a unique DH1024 key and all of the ancient, insecure ciphers in the book (112 bit down to export ciphers, etc. - so accommodating that even Netscape Communicator would be happy). The other Virtual Host is land.org with TLSv1.2 and TLSv1.0 enabled, with 128+ bit ciphers and a unique DH2048 key. The cipher orders for both Virtual Hosts are from strongest to weakest based on known vulnerabilities and cipher strength.
Bob is a user with a modern browser supporting TLSv1.2 Elliptic Curve encryption with contemporary paranoia. He accesses https://land.org on a daily basis.
Alice is a museum curator at the Smithsonian using with an ancient web browser supporting export encryption over SSLv3. She accesses https://land.org on a daily basis to make sure the 10BASE2 connection is still working on the 486DX2. Since the web browser doesn't support SNI, Alice's request falls through a "SNI-hole", returning the default Virtual Host (wonder.land.org), which is a static HTML 2.0 page stating "Your web client does not support Server Name Indication and is vulnerable to a poodle attack. Please consider upgrading your museum exhibit. However, your internet connection does indeed work."
Question (Yes/No): Does this web server compromise Bob's security, or its own (the server's) security? Consider only currently publicly-known vulnerabilities.