Not at all. Depending on what Splashtop's protocol is between their client application (on the support side) and their server, all they have to do is start randomly throwing 9-digit numbers at it. If there's a difference in Splashtop's (or any other company's) response that indicates whether that's a valid client connection number, then you log into the client software and actually attempt to use that number for access. This doesn't give them access to a particular person's computer, just to a computer running Splashtop for remote access.
NOTE: I have seen nothing that makes me believe that Splashtop or any other package (except below) has or has had this kind of vulnerability. They've been around long enough that hopefully if they ever did have this weakness it's long-since been addressed. I'm still going to be a bit paranoid with things that could lead to holes in my clients' security.
As an example of how not to do it both on a company and tech side, I tried out Ammyy once for one session. In the couple minutes between when I had the end user run it and my connecting, someone else connected to that brand-new session (protected only by a numeric key). I don't recall now if I was on the phone or just using text messages, but he said "Oh, I see you on there!" and I freaked since I hadn't connected yet. I think it may have been SMS up to that point, then I called him. Either that person got incredibly lucky, or Ammyy was using (roughly) sequential numbers so all you had to do was get a general range and start plugging numbers in. That was before it became so widely known as being widely used by scammers, but it also ensured that I'd never use it no matter how much they cleaned up their act.
Splashtop doesn't (AFAIK) allow that kind of un-logged-in remote access, but without protocol reassurances or experimentation that I don't have the time or inclination to do, simple 9-digit keys don't have a large-enough address space for me to be comfortable with them.
