If the software reading the XML can't handle invalid input, it might crash, do something unexpected, spontaneously explode (probably not), etc. Those situations can lead to security flaws - but if the software is brittle enough not to be able to handle invalid XML, it will very likely have other security flaws, potentially even in the "valid" data.

As an analogy, most web app security holes (e.g. SQL injection) aren't attacked using invalid HTML, but syntactically valid input which causes problems when parsed. In your case, the XML is the input. Schema checking is rarely sufficient to validate the input, especially if the XSD/DTD/whatever was auto-generated. Whatever processes the input in the application itself needs to check it too.

You should ensure that the correct dtd's and xsd's are referenced for your use case before processing the xml file with a parser (and that mixed xml content is not added such as alternate xmlns, local dtd definitions in the xml, Entity expansions etc).

As I heard on an OWASP podcast OWASP Podcast downloads here, and is particularly relevant in this context, white list your accepted data (xml content), never blacklist your known problems with that content.

Turning off external references is great (think about someone reading your /etc/passwd or /etc/shadow file by referencing it using the file:// protocol instead of the dtd).

You can use an extrinsic validation program/library such as the multi schema validator by Sun/Oracle. http://msv.java.net/ this can provide validation even when there is nothing internally to validate, and can use a different/complementary technology such as RELAX NG to validate your xml.

Be careful about all sorts of injection (SQL, Javascript, xmlns, image, svg, url, xslt, xpath etc) because they can all potentially be injected and transmitted to a context within which they activate and become a danger to your db server, app server or your client environments. Consider a base64 encoded image with an IE compromise that is transmitted into a web-page inside your infrastructure (game over).

Denial of Service on your xml processing infrastructure can also be a worry, but may not be relevant to your system.

Note: @anonymous has provided some great url's for relevant resources.