[eluser]BrianDHall[/eluser]
I think the answer to the op is "yes". As bretticus notes though, it is uncertain as to where it is coming from.
I think its time for Disaster Recovery mode:
First of all, back up everything you have on your server. Zip it and store it.
Now, delete everything on the server you control, wipe it good and clean.
Next, change every password you have for your server. All of them. Email, FTP, control panel, database, anything and everything you can. If any password will be stored in a file on the server, such as the database password, you need to make sure those credentials aren't valid anywhere else. Furthermore, your php database user should not have unrestricted database control, but be limited to the actual roles you need for your scripts to function.
It is comparatively trivial to inject code to find the value of a variable that shouldn't be exposed - and if they expose your db access details and they are the same as your ftp/control panel details? Boom, they have you.
Then, and only then, put together a fresh install of CI and bring your files over into it. If you have access to using SFTP instead of FTP, use it. You can then upload that to get your site online again, ensuring no compromised system files are present.
For additional security, if your site is configured so your scripts aren't allowed to change file permissions with chmod, then set file permissions of your entire CI system (not counting your application) to unwritable by anyone. This will prevent over-writes via php script, if your system is so configured.
Now that you have your site back up, you need to look to see if there is anything in your script that might cause it.
The thing is, the attack on your site was extraordinarily specific. Oddly so. It is most likely that the cause is relatively boring - your account was accessed through stolen username/password, or in some way accessed due to improper configuration in your virtual hosting environment. There are numerous security issues on shared environments, ranging from PHP to Apache to FTP all the way to the underlying operating system (using shell accounts, access to exec() in scripts, and many more).
With this ruled out, you can monitor your new freshly installed and secured site for any such changes. I think it might very well all go away at this point, but it might not so on to the next step.
The next step would then be analyzing your application for possible vulnerabilities. The obvious ones to look for is anywhere a form is processed or an URI is used. It is very easy to make a mistake if you aren't careful, and the worst is when something can be fed to a view or into a function that would permit eval() - it allows them to do anything they could want.
The specificity of the attack is the primary characteristic here - it is highly unlikely a person did this blindly or with a mere security vulnerability in a script.
