They could, but the issue here is not in the specification: it's in running untrusted code. If you allow a jar that you don't trust to load and run, then it could potentially do things that are a lot worse than surfacing a servlet.
Maybe, maybe not. (I don't know for sure). But if you are worried about things that unscrupulous providers might do in their JARs, there are a whole bunch of other nasty things they could do plain old Java. If you are worried about this kind of thing, you really need to insist on getting source code, and do a thorough audit of the code before you let it onto your production servers.
You can use an <absolute-ordering> element in the main web.xml deployment descriptor to list only the jar files in WEB-INF/lib, which you want to be automatically analyzed for annotations and web-fragment.xml descriptors during deployment.
If you do so, the content of web-fragments or annotated classes in other JAR files are not deployed automatically.
You will be able to control this process, quote from here:
The Servlet 3.0 specification also provides an option for instructing the Web Container, whether the container should process the annotations defined on the web components. The name of the element is metadata-complete and it is a child element of web-app element. The metadata-complete element indicates whether the meta-data information available in the deployment descriptor is complete. So, if the value for the metadata-complete element is set to a value of true, then it means that the meta information found in the deployment descriptor is complete and eventually the annotations defined on the web components will be ignored by the Servlet Container. If the value for metadata-complete is set to false, then it means that the information in the deployment descriptor is not complete and web components decorated with annotations, if any, should be scanned and processed by the Web Container.