For critical bugs, the PCI DSS 3.1 Quick Reference Guide covers this in no uncertain terms:
6.2: Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
This is mirrored in the official documentation for PCI DSS 3.2 (I couldn't find a v3.1 PDF) which says exactly the same thing:
6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.
To save you a long read, the TL;DR of requirement 6.1 is that criticality should be measured based on industry provided CVSS scores amplified by business factors.
In more general terms, the question of whether or not they are in violation of PCI DSS when they are running outdated and vulnerable software depends on the decision of their QSA. If the bug is minor, such as a static content injection issue or minor information disclosure, then the QSA may consider it appropriate that the organisation identified the issue and placed it on their risk register for future resolution. If the bug is more severe but not considered critical (e.g. reflective XSS requiring user interaction), the QSA may still consider this a violation of PCI DSS at their discretion.
With regards to EOL software, PCI DSS does not mention it specifically, but simply states that
All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.
This indicates that using EOL software becomes the responsibility of the organisation handling cardholder data. Should a vulnerability be found in the application, it is up to the organisation to mitigate this. This may require them to manually patch the application (difficult, expensive), provide secondary controls (e.g. placing the application in an isolated container environment such as XenApp), or replace the software entirely.
For more information, I suggest you give the PCI DSS documentation a read for yourself. It's quite a long document, but you can skip to sections applicable to your concerns, and the language is quite clear and readable. Also keep in mind that PCI DSS is a standard designed only to encourage sensible security practices around the handling of payment card data - it is not a recipe for strong security on its own, so "PCI compliant" doesn't necessarily mean "secure".