It is a bit difficult to answer in detail when you don't supply critical information such as the system architecture, platform, web server, and framework(s) involved. If things are done right, the risk is negligible. To know whether they're done right and will continue being done right... ay, there's the rub. Which depends on the information I was talking about.
Lacking that information I'm going to pepper my answer with might's and sometimes's; please bear with me.
Are there any security risks that I should be aware of with this configuration?
I can think of some of them, but others surely exist. Many of these are based on the assumption that a vulnerability might exist on the public site, and refer to whether and how it could influence the private site.
session hijacking and gleaning. On some platforms (mainly PHP and *AMP stacks), session data might be stored on the file system, and it might be queryable to any process. Which means that a rogue process on the public web server could enumerate or guess the session data filenames, read them, and disclose information that might be critical.
authentication bypass. Again depending on the platform, it might be possible to trick the secure site into allowing access to a user of the public site. This doesn't bypass network address check, so if you deny private access to external addresses, this specific attack vector is thwarted.
denial of service. Of course, the private site shares some resources with the public site, and can be subject to a denial of service that way.
cross-site attacks. This depends too much on the site's structure to give details. Broadly said, there are security measures in place to avoid
victimsite.com to supply code that calls home to
evilhost.com. Many of these measures work less, or not at all, if the two sites are of the form
private.site.com. This vector of attack involves someone supplying a link to the public site to a victim on the inside (e.g. through an e-mail), and cross-site scripting code on the public site that would attempt to steal information or wreak havoc on the private site. If this works, i.e., if the public site is vulnerable to this kind of attack, then it will work much better on the private site on the same domain, than if it was on a different domain.
shared, shareable, or forceable connections. If the public site is broken into, an attacker is already inside the identification perimeter of the private site. Assuming he can recover the needed credentials (and on some platforms, this is possible - it requires non-default hardening to prevent it), he can identify himself to other hosts, e.g. the database with confidential information, and stand a much better (on most *AMPs, approaching 100% from the wrong side) chance of being allowed access.
code-level access. This isn't too likely, for it would require other vulnerabilities, to wit: write access by the Web server process, and same level of access between subprocesses belonging to the public and private sites. Still, except for a few happy exceptions (Debian and Ubuntu), this is often the default configuration unless specific steps are taken by the sysadmin. At worst, this allows a vulnerability on the public site to grant an attacker full access to everything from passwords onwards relating to the private site, as well as modifying information and reporting, intercepting some kinds of traffic (think "webmail"), and destroy data.
On a properly secured system (e.g. here, points 6 onwards; some pointers on PHP; and of course OWASP), I'd have few worries. Still enough to ask myself, must I really do this?; it's not like server space is all that expensive anymore. But very few. Especially if the sysadmins keep up with the necessary advisories.
On the other hand, placing a private and supposed-to-be-secure site on a system installed out of the box and not too well maintained (e.g. a stock Wordpress installation) is tantamount to conjuring up Murphy at its worst, and I can't advise too strongly against it.