The key point here is:

In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3.

These applies to old Kubernetes versions which are not supported any more and you are not supposed to use them on production systems. If you want to familiarize with Kubernetes version support policy, please refer to this article. As you can read in it:

The Kubernetes project maintains release branches for the most recent three minor releases. Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.

Currently they are: 1.13, 1.14 and 1.15 versions.

As you can see here or here the vulnerability was made public in December 2018 so I wouldn't say that in terms of contemporary software development process standards it is recently. It doesn't make sense to deliberate if its safe or not to use some software with vulnerabilities/bugs which are already fixed in newer versions, available from a long time.

If you are interested in this bug, you can analyze this GitHub issue or read a nice description of it in this article. As you can read:

The bug allows an attacker who can send a legitimate, authorized request to the API server to bypass the authorization logic in any sequenced request. In other words, escalate privileges to that of any user.

In other words: to be able to bypass the authorization logic in subsequent requests or to escalate privileges, such user needs to be able to send legitimate, authorized requests to the API server.

So at this point you can probably answer your question yourself. The key point isn't the fact that the network is public or private. More important is how it is secured and by whom it can be accessed. Generally private networks with no external access (e.g. intranets) tend to be more secure but if it comes to things like possible privilege escalation by someone who already has some level of access, it is potentially dangerous even within organization.