A lil confused as the diffs between Python, Jython and CPython. I understand Jython is an implementation of Python in Java and CPython is the same except that it is implemented in C.
But what I'm confused on really is identifying vulnerabilities in Python. Such as the two below.
For example - CVE-2016-5636 - Here it appears that the vulnerability can't be reproduced in Jython.
https://bugzilla.redhat.com/show_bug.cgi?id=1345857
Similarly looking at - CVE-2016-5699 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5699
It says "CRLF injection vulnerability in the HTTPConnection.putheader function in urllib2 and urllib in CPython (aka Python) before 2.7.10 and 3.x before 3.4.4 allows remote attackers to inject arbitrary HTTP headers via CRLF sequences in a URL."
Does this mean CVE-2016-5699 is not vulnerable in Jython?
So overall- What I'm wondering is if a vulnerability in Python means it is vulnerable in Jython?
Not necessarily. When you refer to such things as "Python", you are potentially referring to two different things:
Normally the Python language doesn't change (much) across different implementations. What changes is how the language is processed, including what external system functions are called.
Python without any other distinction would normally refer to CPython, the standard implementation. Others, as you mention above, are Jython and IronPython. Each of these runs in a different VM: JVM for Jython and dotnet for IronPython. These VMs might, for example, allocate memory differently thus preventing a memory-based error from occurring in a different VM. In the case of CVE-2016-5636 mentioned, it's noted that Jython calls the Java version of zip, while CPython likely calls the C version of zip.
In short - if the flaw occurs in how the language approaches a problem, it's likely to affect all implementations. Otherwise, you will need to check each platform's vulnerability on an individual basis.
Addendum: According the Red Hat tracker for CVE-2016-5699, this is language error and therefore is likely (but not guaranteed) to be vulnerable in all implementations until updated.