A flaw was found in Apicurio Registry's WSDL validation path. The WSDLReaderAccessor constructs a wsdl4j WSDLReader without disabling the javax.wsdl.importDocuments feature:

```java
WSDLFactory wsdlFactory = WSDLFactory.newInstance();
wsdlReader = wsdlFactory.newWSDLReader();   // no setFeature() calls
```

wsdl4j 1.6.3's WSDLReaderImpl defaults javax.wsdl.importDocuments to true. When WsdlContentValidator.validate() runs at ValidityLevel.FULL, it calls readWSDL() which recursively fetches every <wsdl:import location="..."> and <xsd:import schemaLocation="..."> URL over the network using java.net.URL.openStream() with no allow-list.

An attacker with Developer-role access (or unauthenticated when the registry runs with default configuration) can set the VALIDITY rule to FULL on any artifact, then upload a WSDL document with attacker-controlled import locations pointing to internal services. The registry pod will issue HTTP GET requests to those URLs, enabling server-side request forgery against in-cluster services, cloud metadata endpoints, or other internal infrastructure. The error message in the RuleViolationException may leak partial response content from the target.

The precondition (VALIDITY rule set to FULL) is settable by any Developer-role user via the REST API, so the attacker controls both the precondition and the exploit.

Affected file: schema-util/wsdl/src/main/java/io/apicurio/registry/wsdl/util/WSDLReaderAccessor.java
Upstream: https://github.com/Apicurio/apicurio-registry

Remediation: Disable import dereference by calling wsdlReader.setFeature("javax.wsdl.importDocuments", false) and wsdlReader.setFeature("com.ibm.wsdl.parseXMLSchemas", false). Long-term, replace wsdl4j (unmaintained since 2013) with Apache Woden or restrict WSDL validation to SYNTAX_ONLY.